Method for implementation by a vehicle control unit for the multimodal use of a vehicle screen, computer program, device and vehicle

Abstract

Exemplary embodiments of the present invention provide a method for implementation by a vehicle control unit for the multimodal use of a vehicle screen. In a first operating mode, the method comprises receiving screen content to be displayed and sending the screen content to an image memory coupled to the screen. In a second operating mode, the method comprises receiving a first screen content to be displayed, receiving at least a second screen content to be displayed, and generating at least one virtual screen driver. The method further comprises, in the second operating mode, sending the first screen content to be displayed from the virtual screen driver to a first sub-area of ​​the image memory and sending the second screen content to be displayed to a second sub-area of ​​the image memory, which is different from the first sub-area.

Description

[0001] Exemplary embodiments of the present invention relate to a method for implementation by a vehicle control unit for the multimodal use of a vehicle screen, a computer program, a device and a vehicle.

[0002] For example, Android 15 (brand) supports multiple users, allowing them to use their own display and audio zone as a single source, or to share content across multiple displays and audio zones. Traditionally, separate, interconnected display panels can be used to create an ultra-wide display (UWD). However, in a vehicle, a single screen can be advantageous due to space and cost constraints; for instance, a 32:9 theater screen or ultra-wide front display can be used. This makes it more difficult, compared to using separate screens, for individual users to consume content independently.Conventional approaches with multiple displays arranged in a row and independent drivers cause usage limitations, as the screen is either exclusively available to one user, content can only be displayed sequentially, or artifacts and latency occur in the display of individual or multiple content items.

[0003] DE 112010 004 601 T5 discloses a method for controlling multiple displays from a single graphics stack. The method comprises writing frame data to a single virtual frame buffer from a single graphics stack, moving the frame data from the single virtual frame buffer to multiple display buffers, and updating multiple displays.

[0004] There is therefore a need to provide an improved method for the multimodal use of a vehicle screen. The method, the device, the computer program, and the vehicle, according to the independent claims, address this need.

[0005] The implementation examples are based on the core idea of ​​configuring the display driver so that at least the following two usage scenarios are possible with only one screen and without artifacts: 1) Single User – for example, ultra-wide-screen display, 2) Multi-User – for example, partitioned wide-screen display. Touch functionality should be retained in each scenario. This is achieved through virtualization of sub-areas of the screen.

[0006] Exemplary embodiments relate to a method for implementation by a vehicle control unit for the multimodal use of a (single) vehicle screen. In a first operating mode, the method comprises receiving screen content to be displayed and sending the screen content to an image memory connected to the screen. In a second operating mode, the method further comprises receiving a first screen content to be displayed, receiving at least a second screen content to be displayed, and generating at least one virtual screen driver. In the second operating mode, the first screen content to be displayed is further sent by the virtual screen driver to a first sub-area of ​​the image memory, and the second screen content to be displayed is sent to a second sub-area of ​​the image memory, different from the first sub-area. Screen content refers to visual information that can be displayed on the screen.The two screen contents can be obtained, for example, from different user contexts or from different virtual machines. The term "user context" refers to a software environment in which a user interacts with a device (e.g., the screen). The different user contexts or virtual machines can operate on a common platform, such as the control unit, the screen, or another device.

[0007] The two sub-areas can, for example, each correspond to contiguous pixel areas of the screen.

[0008] The creation of the virtual display driver can be implemented using a software or hardware module, or a combination thereof. For example, the virtual display driver can be implemented using at least one of the following techniques: hardware-based compositing with a system-on-chip (SoC) or graphics processing unit (GPU), Wayland configuration or virtual monitor, hypervisor configuration or driver routing, platform driver integration or software and hardware compositing, display controller, and display-based software and hardware compositing.

[0009] The virtual display driver behaves like a physical display driver, even though no dedicated physical display hardware is present. Like a physical driver, the virtual display driver registers with the operating system as a display adapter and simulates a screen by writing graphics output to frame buffer memory instead of rendering it to a physical screen. A portion of the framebuffer (frame buffer) is provided as a "virtual screen" into which graphics data can be written. The input and output logic, for example, for a dedicated user context, is then handled by the virtual driver and the allocated memory area.

[0010] By using the virtual driver, the aforementioned usage scenarios (operating modes) can be implemented with only one physical driver (e.g., a driver IC for controlling the screen). For example, in the first operating mode, 100% of the screen can be used. For partial use, in the second operating mode, the left and right halves can be dynamically reconfigured, or one half can be static and the other dynamic. In this way, artifacts can be prevented, and the transition from one operating mode to another can be implemented quickly and without synchronization artifacts.

[0011] Switching from the first to the second operating mode, or from the first to a third operating mode described below and then to the second operating mode, can occur automatically, for example, upon detection of a second connected virtual machine or a second user context, or by enabling a user.

[0012] In one embodiment, the first and second screen contents can be separated both in terms of content and interaction. This means that different content is displayed on the two sub-areas, which can be controlled and used independently. This separation can occur at the content level (different information) or at the interactive level (independent user interactions). Content separation refers to the fact that the two screen sub-areas display different data or applications, namely the first and second screen contents. Interactive separation means that user interactions (i.e., input signals generated, for example, by mouse, keyboard, or touchscreen) are applied independently to the respective screen contents.For example, the first screen content can be influenced by a first user via touch or gesture control, while the second screen content is controlled by a second user via a different touch area or voice input.

[0013] In one embodiment, the second screen content can be sent to the frame buffer by a second virtual driver. This would correspond to the dynamic configuration of both sub-areas mentioned above. This allows the frame buffer to be divided so that the sub-areas do not overlap, or only minimally, and are controlled independently. This simulates the presence of two physical drivers, as would be the case with two separate monitors. Alternatively, the second sub-area can also be controlled statically by the physical driver. In this case, the second sub-area can correspond to the entire frame buffer. The second screen content can be modified so that the user-desired output is fully displayed on a portion of the second sub-area (for example, a portion disjoint from the first sub-area), while the remainder is rendered as "free," for instance.The first screen content can then be rendered on this remaining space by the (first) virtual driver (as an overlay).

[0014] In one embodiment, the method can generate a virtual interaction layer for the first or second sub-area of ​​the image memory. The interaction layer is a software layer for which the sub-area is defined as the target, for example, by coordinates or other window information. It interprets user input on the screen, for instance, according to context-specific rules. For example, a swipe gesture on the touchscreen in the first sub-area can be interpreted as "scrolling" and accordingly forwarded to control the target application.

[0015] In one embodiment, the first section of the image memory can comprise between 40 and 60 percent of the total image memory. The image memory can be divided, for example, into a left and a right section. For use by two people, it can be advantageous to divide the screen approximately equally. Similarly, it would be possible to define the first section as the main display, for example, for the driver, while the remaining pixels are shared by a passenger and other vehicle occupants.

[0016] In one embodiment, the method further comprises acquiring sensor data from a touchscreen and, in the second operating mode, assigning this data to either a first sub-area of ​​the touchscreen, which corresponds to the first sub-area of ​​the image memory, or to a second sub-area of ​​the touchscreen, which corresponds to the second sub-area of ​​the image memory. This sensor data represents touch or input positions on the touchscreen and serves to enable interaction between the user and the application displayed on the screen. The assignment of the sensor data to a specific sub-area of ​​the touchscreen is based on the input position. Each sub-area of ​​the touchscreen is logically connected to a corresponding sub-area of ​​the image memory.This link enables precise synchronization of interactions within the respective area of ​​the touchscreen with the corresponding image data in the image memory. The sensor data is then passed on, for example, to control or interact with an application running in an initial user context or on an initial virtual machine.

[0017] Furthermore, the process can include acquiring additional sensor data from the touchscreen and assigning this data, in the second operating mode, to the other of the first and second sections of the touchscreen. This additional sensor data is then passed on, for example, to control or interact with another application running in a second user context or on a second virtual machine. The two applications can be controlled simultaneously in multi-user mode.

[0018] Dividing the touchscreen into two sections allows the screen's touch functionality to be used independently in multi-user scenarios. This can be achieved by virtualizing the touchscreen, creating interaction layers for each section. Each of the independent display layers (the first and second sections of the image memory) can then have its own interaction layer. Certain interaction layers can be deactivated, for example, for the driver, while others, such as for the passenger, remain active.

[0019] Compared to conventional techniques, driver virtualization enables a smooth transition between operating modes without artifacts. For example, in a third operating mode, the process can involve switching from the first to the second mode, with the screen content of the first mode fading out and the content of both the first and second modes fading in. Fading out and fading in is a visual transition effect where the display of the image content is gradually changed to allow for a seamless change. During the fade-out, the brightness or transparency of the image content is gradually reduced. This can be achieved by successively decreasing the alpha values ​​(in transparency-based techniques) or the brightness intensity over a defined period. Conversely, during the fade-in, the brightness or transparency of the image content is gradually increased.

[0020] A fourth operating mode can correspond to the synchronized display of content for multiple users, i.e., a sharing scenario. In this case, the process can further include receiving screen content to be displayed and synchronously sending this content to the first and second sub-areas of the image memory. The screen content can be transferred to both sub-areas in near real-time. By using the virtual driver, latency can be kept low to improve synchronous display. Synchronization mechanisms such as timestamps or sequence numbers in the virtual driver can be used to display the screen content in the correct order on both sub-areas. The screen content is displayed identically on both sub-areas.Scaling mechanisms can be applied in the virtual driver to clearly display the content regardless of the size of the sub-areas.

[0021] In one embodiment, the method further comprises receiving audio content and, in the second operating mode, creating an audio zone for playing back the audio content. The audio zone is assigned to the first screen content. The method includes synchronously sending the first screen content to the first sub-area of ​​the image memory and the audio content to the audio zone. The audio content refers to acoustic information, which is encoded, for example, in digital form.

[0022] An audio zone can be created, for example, by playing audio content in a specific room or environment. This is achieved by playing audio through speakers located within the target area. An audio zone can also be created virtually within a room, for example, using directional speakers, beamforming, or headphone systems. If multiple audio zones are created, each can play individual audio content. The content can be played synchronously or independently.

[0023] For the two screen sections, for example, two audio zones can be created for the respective users. In these audio zones, audio content can be played independently of each other, synchronized with the screen content of the respective sections, such as a video stream.

[0024] Exemplary embodiments also include a computer program for carrying out one of the methods described herein, if the computer program runs on a computer, a processor, or a programmable hardware component.

[0025] Another embodiment is a device, such as a vehicle control unit, for the multimodal use of a vehicle screen. The device includes an interface for communication with the screen and optionally other devices from which the content to be displayed is received or via which it is controlled. The device includes a data processing circuit configured to carry out at least one of the methods described herein. Further embodiments provide a vehicle with a device as described herein.

[0026] Examples of implementation are explained in more detail below with reference to the accompanying figures. These show: Fig. Figure 1 shows a schematic representation of an example of a method for execution by a vehicle control unit for the multimodal use of a vehicle screen; Fig. Figures 2a-2c show block diagrams of an example of a device for carrying out a method described herein in the first, second and fourth or third operating modes; and Fig. Figure 3 shows a block diagram of another example of a device for carrying out a method described herein.

[0027] Several embodiments are now described in more detail with reference to the accompanying drawings, in which some of these embodiments are illustrated. For the sake of clarity, the thickness dimensions of lines, layers, and / or regions may be exaggerated in the figures.

[0028] Fig. Figure 1 shows a schematic representation of an example of a method 100 for execution by a vehicle control unit for the multimodal use of a vehicle screen. The method 100 can, for example, be executed by a processing circuit of the vehicle control unit.

[0029] Method 100 comprises, in a first operating mode, receiving 110 a screen content to be displayed and sending 120 the screen content to an image memory coupled to the screen. Method 100 further comprises, in a second operating mode, receiving 130 a first screen content to be displayed, e.g., from a first virtual machine or a first user context, receiving 140 at least a second screen content to be displayed, e.g., from a second other virtual machine or a second other user context, and generating 150 at least one virtual screen driver.Furthermore, the method comprises sending 160 of the first screen content to be displayed from the virtual screen driver to a first sub-area of ​​the image memory and sending 170 of the second screen content to be displayed (e.g., by the physical screen driver or another virtual screen driver) to a second sub-area of ​​the image memory that is different from the first sub-area. The first sub-area and the second sub-area can, for example, be overlapping or disjoint.

[0030] As described above, in addition to the display itself, the touchscreen and audio zones can also be controlled separately.

[0031] By utilizing the virtual driver, an ultrawide display, for example, can support both single-user and multi-user applications. The solution envisions, for instance, that the display, connected to an ECU (Electronic Control Unit), can flexibly cover various use cases. In single-user mode, the entire width of the display can be used seamlessly and without visible artifacts, including touch functionality. For multi-user mode, the screen can be divided into different areas, with each user able to access a right or left area, optionally separated by a central zone that both can operate. Furthermore, the proposed solution allows for smooth transitions between these modes through morphing animations without any visual disruption. In an optional sharing mode, the same content can be displayed synchronously on both sides without any delay.Different user contexts can be realized by combining virtual displays into an ultra-wide screen, while audio zones provide supplementary content, for example via speakers or headphones.

[0032] For example, in the first operating mode, 100% of the screen can be used. For partial use, in the second operating mode, the left and right halves can be dynamically reconfigured, or one half can be static and the other dynamic. This prevents artifacts and allows for a quick transition between operating modes.

[0033] Further details and aspects of Method 100 are mentioned in connection with the above description or the embodiments described below. The Fig. 1 The embodiment shown may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more embodiments described below (e.g. Fig. 2a-c) will be mentioned.

[0034] Fig. Figures 2a-2c show block diagrams of an example of a device 200 for carrying out a method described herein, for example method 100, in the first, second, and fourth or third operating modes. The device may, for example, be part of a vehicle control unit and include a processing circuit for carrying out the method.

[0035] In the specific example of Fig. 2a-2c is intended as operating system 210 of device 200 “Android Automotive v15 (brand)” (or subsequent versions) with multi-display and multi-user mode support. “Android Automotive OS (brand)” (Operating System) is an operating system from “Google (brand)” specifically designed for use in vehicles. It is based on the open-source project “Android (brand)” and is a standalone version of the operating system that can be directly integrated into a vehicle's hardware and software. Alternatively or additionally, other operating systems can also be used.

[0036] The device 200 also includes a physical display driver 220, which controls the image memory of a screen 230 (here: an ultra-wide display). In the example of Fig. 2a The device 200 implements a first operating mode: The device 200 receives a screen content to be displayed, for example via a communicative coupling with an external device or via an application running on the control unit, and sends the screen content to an image memory coupled to the screen 230 via a communicative coupling with the image memory.

[0037] A virtual driver 240 is included in the software of driver 220, but remains deactivated in the first operating mode. In this first operating mode, the user can therefore use the screen 230 as a full-screen display. Optional touch functionality can also be provided across the entire screen 230.

[0038] In the example of Fig. 2b The device 200 implements a second operating mode. The device 200 receives, for example via a communicative link with the above or another device, a first screen content to be displayed and, via a communicative link with the same device but from a different application on that device, at least a second screen content to be displayed. The device 200 creates or activates the virtual screen driver 240 and sends the first screen content to be displayed from the virtual screen driver to a first sub-area 231 of the image memory and the second screen content to be displayed (via the physical driver or another virtual driver) to a second sub-area 232 of the image memory, which is different from the first sub-area. In the example of Fig. 2b the two sub-areas 231, 232 correspond to the left 60% and the right 40% of screen 230 respectively.

[0039] Using a virtual driver can support multimodal screen usage, i.e., in both the first and second operating modes. On the one hand, full-screen display and touch operation can be implemented for a single-user context without artifacts or visible seams; on the other hand, a multi-user mode with a partitioned screen can be implemented.

[0040] The touch functionality is also divided, i.e. the device 200 receives sensor data from the touch screen of the screen 230, assigns this either to a first sub-area of ​​the touch screen, which is assigned to the first sub-area 231, or to a second sub-area of ​​the touch screen, which is assigned to the second sub-area 232.

[0041] The configuration of Fig. 2b can also be used for a fourth operating mode. This fourth mode corresponds to shared use between vehicle occupants: the left and right sides then display the same content synchronously. Thanks to the virtual driver, this can happen without any visible time delay.

[0042] In the example of Fig. 2c implements a third operating mode for the device 200. In this mode, the device 200 switches from the first to the second operating mode, or vice versa. That is, the screen content of the first operating mode is faded out, and the first and second screen contents are faded in, or vice versa. Thus, after a predetermined time, the display 230a with split usage changes to the display 230b with single usage. The initially activated virtual driver 240a is deactivated in the process.

[0043] The Device 200 can combine screen content from the first and second operating modes, and optionally other modes as well, before transmitting it to the Ultra-Wide Display 230, through an overlapping configuration of display drivers. Furthermore, the Device 200 can separate touch controls for the left and right portions of the Screen 230.

[0044] Optionally, a separator can be provided in the second operating mode to separate the left from the right side. The separator suppresses touch sensor data generated within the separator area, as it cannot be clearly assigned to either side.

[0045] In general, a separator could be configured as follows: In the second operating mode, a device according to the invention can be configured to receive sensor data from the touchscreen of the display and to assign the sensor data to either a first sub-area of ​​the touchscreen, which is assigned to the first sub-area of ​​the image memory, to a second sub-area of ​​the touchscreen, which is assigned to the second sub-area of ​​the image memory, or to a third sub-area of ​​the touchscreen (the separator). The third sub-area of ​​the touchscreen is assigned to a third sub-area of ​​the image memory. This third sub-area of ​​the image memory is adjacent to the first sub-area of ​​the image memory or is arranged between the first and second sub-areas. The device is configured to discard the sensor data if it is assigned to the third sub-area of ​​the touchscreen. The third sub-area of ​​the image memory can, for example, be...They make up 3 to 5 percent of the total image memory.

[0046] Fig. Figure 3 shows a block diagram of a further embodiment of a device 30 for implementation by a vehicle control unit for the multimodal use of a vehicle screen of a vehicle 40. The vehicle screen can, for example, be an ultra-wide display (UWD). The ultra-wide display can be located in a front area of ​​the vehicle, for example, a UWD driver compartment 50. The ultra-wide display can be located in a rear area of ​​the vehicle, for example, a UWD passenger compartment 52. The device 30 includes an interface 32 for communication with the screen, such as the UWD 50 or 52. The device 30 further includes a (data) processing circuit 34, which is configured to carry out at least one of the methods described herein, for example, method 100. Further embodiments include a vehicle 40 comprising a device 30.

[0047] The in Fig. The interface 32 shown in Figure 3 can, for example, correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information, such as digital bit values ​​based on a code, within a module, between modules, or between modules of different entities. The interface 32 can, for example, be configured to communicate with other network components via a (radio) network or a local area network.

[0048] In exemplary embodiments, the data processing circuit 34 can correspond to any controller or processor, or to a programmable hardware component. For example, the data processing circuit 34 can also be implemented as software programmed for a corresponding hardware component. In this respect, the data processing circuit 34 can be implemented as programmable hardware with appropriately adapted software. Any processor, such as digital signal processors (DSPs), can be used. These exemplary embodiments are not limited to a specific type of processor. Any processor, or even multiple processors, are conceivable for implementing the data processing circuit 34.

[0049] As in Fig. As shown in Figure 3, the interface 32 can be coupled to the respective data processing circuit 34 of the device 30. In examples, the device 30 can be implemented by one or more processing units, one or more processing devices, or any means of processing, such as a processor, a computer, or a programmable hardware component that can be operated with appropriately adapted software. Likewise, the described functions of the data processing circuit 34 can also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components can be a general-purpose processor, a digital signal processor (DSP), a microcontroller, etc.The data processing circuit 34 can be able to control the interface 32, so that any data transmission that takes place via the interface 32 and / or any interaction in which the interface 32 may be involved can be controlled by the data processing circuit 34.

[0050] In one embodiment, the device 30 may comprise a memory and at least one data processing circuit 34 which is functionally coupled to the memory and configured to perform one of the methods described above.

[0051] In examples, interface 32 can correspond to any means of receiving, receiving, transmitting, or providing analog or digital signals or information, such as any connector, contact, pin, register, input terminal, output terminal, conductor, track, etc., that enables the provision or receipt of a signal or information. Interface 32 can be wireless or wired and can be configured to communicate with other internal or external components, such as sending or receiving signals or information.

[0052] In at least some embodiments, the vehicle 40 can correspond, for example, to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, a bus, a motorcycle, an all-terrain vehicle, a motor vehicle, or a truck. The device 30 can, for example, be a part of or a control unit of the vehicle 40.

[0053] Further details and aspects will be mentioned in connection with the exemplary embodiments described above. The in Fig. The embodiment shown in Figure 3 may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more of the above (e.g., Fig. The exemplary embodiments described in sections 1-2c) have been mentioned.

[0054] Further embodiments include computer programs for carrying out one of the methods described herein, when the computer program runs on a computer, a processor, or a programmable hardware component. Depending on specific implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be carried out using a digital storage medium, for example, a floppy disk, a DVD, a Blu-ray disc, a CD, a ROM, a PROM, an EPROM, an EEPROM, a FLASH memory, a hard disk, or other magnetic or optical storage media on which electronically readable control signals are stored. These control signals can interact with, or interact with, a programmable hardware component in such a way that the respective method is carried out.

[0055] A programmable hardware component can be a processor, a computer processor (CPU = Central Processing Unit), a graphics processor (GPU = Graphics Processing Unit), a computer, a computer system, an application-specific integrated circuit (ASIC = Application-Specific Integrated Circuit), an integrated circuit (IC = Integrated Circuit), a system-on-a-chip (SOC = System on Chip), a programmable logic element, or a field-programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array).

[0056] The digital storage medium can therefore be machine-readable or computer-readable. Some embodiments thus include a data carrier containing electronically readable control signals capable of interacting with a programmable computer system or a programmable hardware component to perform one of the methods described herein. An embodiment is therefore a data carrier (or a digital storage medium or a computer-readable medium) on which the program for performing one of the methods described herein is recorded.

[0057] In general, embodiments of the present invention can be implemented as a program, firmware, computer program, or computer program product with program code or as data, wherein the program code or data is / are effective in carrying out one of the methods when the program runs on a processor or a programmable hardware component. The program code or data can, for example, also be stored on a machine-readable medium or data carrier. The program code or data can be in the form of, among other things, source code, machine code, bytecode, or other intermediate code. Reference symbol list 30 Device 32 interface 34 Data processing circuit 40 vehicles 50" ultra-wide display in the driver's compartment 52" ultra-wide display in the passenger compartment 100 procedures 110 Procedure Step Obtain 120 Process step Send 130 Procedure Step Obtain 140 Process step Send 150 Process step: Generate 160 Procedure Step Obtain 200 Device 210 Operating System 220 drivers 230 screen 230a screen in second operating mode 230b screen in first operating mode 231 first sub-area 232 second sub-area 240 virtual drivers 240a enabled virtual driver 240b disabled virtual driver

Claims

Method (100) for implementation by a vehicle control unit for the multimodal use of a vehicle screen, comprising: in a first operating mode: receiving (110) a screen content to be displayed; and sending (120) the screen content to an image memory coupled to the screen; in a second operating mode: receiving (130) a first screen content to be displayed; receiving (140) at least a second screen content to be displayed; and generating (150) at least one virtual screen driver; sending (160) the first screen content to be displayed from the virtual screen driver to a first sub-area of ​​the image memory; and sending (170) the second screen content to be displayed to a second sub-area of ​​the image memory, different from the first sub-area. Method (100) according to claim 1, wherein the first and the second screen content to be displayed are separated in terms of content and interaction. Method (100) according to one of the preceding claims, wherein the second screen content is sent to the image memory by a second virtual driver. Method (100) according to one of the preceding claims, further comprising generating a virtual interaction layer for the first or the second sub-area of ​​the image memory. Method (100) according to one of the preceding claims, wherein the first sub-area of ​​the image memory constitutes between 40 and 60 percent of the total image memory. Method (100) according to one of the preceding claims, further comprising: obtaining sensor data from a touch screen of the display; and in the second operating mode: assigning the sensor data to either a first sub-area of ​​the touch screen which is assigned to the first sub-area of ​​the image memory, or to a second sub-area of ​​the touch screen which is assigned to the second sub-area of ​​the image memory. Method (100) according to one of the preceding claims, further comprising: in a third operating mode: switching from the first to the second operating mode, wherein the screen content of the first operating mode is hidden and the first and the second screen content are displayed. Method (100) according to one of the preceding claims, further comprising: in a fourth operating mode: receiving a screen content to be displayed; and synchronously sending the screen content to be displayed to the first and the second sub-area of ​​the image memory. Method (100) according to one of the preceding claims, further comprising: receiving an audio content; in the second operating mode: creating an audio zone for playing the audio content, wherein the audio zone is assigned to the first screen content; synchronously sending the first screen content to the first sub-area of ​​the image memory and the audio content to the audio zone. A computer program for carrying out one of the methods according to one of the preceding claims, wherein the computer program runs on a computer, a processor, or a programmable hardware component. A device (30) for implementation by a vehicle control unit for the multimodal use of a vehicle screen, comprising: an interface (32) for communication with the screen; and a data processing circuit (34) configured to carry out at least one of the methods according to any one of claims 1 to 9. A vehicle (40) with a device according to claim 11.

Images