Startup display method and device, electronic equipment and storage medium

Abstract

The invention provides a startup display method and device, electronic equipment and a storage medium, and relates to the technical field of computing resource management. The method comprises the steps that in response to a detected startup instruction, startup content and startup log information are obtained, and the startup log information is generated in the startup process of the electronic equipment; loading a first layer picture in a screen of the electronic equipment, wherein the startup content is presented in the first layer picture; a second layer picture is loaded in a target area of the screen, the starting log information is presented in the second layer picture, and the second layer picture covers the first layer picture. According to the scheme, coexistence display of the startup log information and the startup content can be realized in the startup process of the electronic equipment.

Description

Technical Field

[0001] This disclosure relates to the field of display technology for electronic devices, and more specifically, to a power-on display method, apparatus, electronic device, and storage medium. Background Technology

[0002] During the boot process of electronic devices, it is usually necessary to output boot log information generated by the kernel and system services to a display device for system debugging and status monitoring. Currently, the common implementation method is to use the framebuffer console (fbcon) mechanism to display the log text directly on the screen in full screen.

[0003] However, because the framebuffer console mechanism uses a single framebuffer for full-screen rendering, when displaying the startup log, it will completely cover the main display content such as the boot animation and brand logo output during the boot loader or initialization phase, or the log text will be covered by subsequent boot content, resulting in a conflict between log information and boot content.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this disclosure is to provide a boot-up display method, apparatus, electronic device, and storage medium that enables the coexistence and display of boot log information and boot content during the boot-up process of an electronic device.

[0006] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0007] According to a first aspect of the present disclosure, a method for powering on and displaying data is provided, comprising: In response to the detection of a power-on command, the device acquires power-on content and startup log information, wherein the startup log information is generated during the power-on process of the electronic device; A first layer of screen is loaded onto the screen of the electronic device, the first layer of screen displaying the boot content; and A second layer of screen is loaded in the target area of ​​the screen. The second layer of screen displays the startup log information and is overlaid on the first layer of screen.

[0008] In some example embodiments of this disclosure, based on the foregoing scheme, loading the second layer of image in the target area of ​​the screen includes: Determine the target overlay layer from one or more candidate overlay layers; The startup log information is bound to the target overlay layer, and the second layer of the target overlay layer is loaded in the target area of ​​the screen. The second layer displays the startup log information bound to the target overlay layer.

[0009] In some example embodiments of this disclosure, based on the foregoing scheme, binding the startup log information to the target overlay layer includes: Render the startup log information to the target memory area; Register the target memory region carrying the startup log information as a framebuffer object managed by the rendering manager, and generate a corresponding framebuffer object identifier. Bind the framebuffer object identifier to the target overlay layer.

[0010] In some example embodiments of this disclosure, based on the foregoing scheme, rendering the startup log information to the target memory region includes: Request the target memory region; Obtain the writable virtual address of the target memory region using memory mapping; The startup log information is rendered to the target memory region where the writable virtual address is located.

[0011] In some example embodiments of this disclosure, based on the foregoing scheme, rendering the startup log information to the target memory region includes: The kernel-stored log text is parsed line by line to obtain the startup log information; The startup log information is rendered to the target memory area according to the built-in character set.

[0012] In some example embodiments of this disclosure, based on the foregoing scheme, the startup log information is presented in the second layer of the screen, including: New startup log information is obtained at a specified period, or new startup log information is generated during the power-on process of the electronic device, and the new startup log information is displayed in the second layer screen.

[0013] In some example embodiments of this disclosure, based on the foregoing scheme, the size of the second layer image is smaller than the size of the first layer image.

[0014] In some example embodiments of this disclosure, based on the foregoing scheme, the method further includes: After the electronic device has finished powering on, the second layer screen is turned off and its resources are released. The desktop is displayed in the first layer of the screen.

[0015] In some example embodiments of this disclosure, based on the foregoing scheme, the method further includes: After the electronic device has finished powering on, the desktop is displayed in the first layer of the screen; The second layer of the screen is displayed in the target area of ​​the screen using a lease isolation method, and the startup log information is presented in the second layer of the screen.

[0016] In some example embodiments of this disclosure, based on the foregoing scheme, the second layer image adopts a pixel format that supports transparency channels, so that the second layer image covers the first layer image in a semi-transparent or opaque manner.

[0017] According to a second aspect of the present disclosure, a power-on display device is provided, applied to an electronic device, the device comprising: The information acquisition module is used to acquire boot content and boot log information in response to the detection of a power-on command, wherein the boot log information is generated during the power-on process of the electronic device; A screen loading module is used to load a first layer of screen onto the screen of the electronic device, the first layer of screen displaying the boot content; and The screen loading module is also used to load a second layer of screen in the target area of ​​the screen. The second layer of screen displays the startup log information and is overlaid on the first layer of screen.

[0018] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions that, when executed by the processor, implement the power-on display method as described in the first aspect.

[0019] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the boot-up display method as described in the first aspect.

[0020] The technical solutions provided in this disclosure can include the following beneficial effects: The power-on display method in the example embodiments of this disclosure, in response to detecting a power-on command, acquires power-on content and startup log information, the startup log information being generated during the power-on process of the electronic device; by loading a first layer of screen on the screen of the electronic device, the first layer of screen displaying the power-on content, and simultaneously loading a second layer of screen in a target area of ​​the screen, the second layer of screen displaying the startup log information, and the second layer of screen overlaying the first layer of screen, the power-on content and startup log information are respectively carried in two independent layers of screen, and visual collaborative display is achieved through spatial layout (target area) and hierarchical relationship (overlay), so that the power-on content can be displayed in the first layer of screen without interruption, and the startup log information is overlaid in the target area of ​​the screen through the second layer of screen, effectively solving the conflict problem of startup log information and power-on content in display resources, and realizing non-intrusive coexistence and synchronous visualization of startup log information and power-on content throughout the entire power-on process.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0023] Figure 1 The schematic diagram illustrates a power-on display method according to some embodiments of the present disclosure.

[0024] Figure 2 The illustration schematically shows a process diagram of loading a second layer of image in a target area of ​​a screen according to some embodiments of the present disclosure.

[0025] Figure 3 The schematic diagram illustrates a power-on display method according to some other embodiments of the present disclosure.

[0026] Figure 4 The schematic diagram illustrates a power-on display method according to some other embodiments of the present disclosure.

[0027] Figure 5 A schematic diagram of a power-on display device according to some embodiments of the present disclosure is shown.

[0028] Figure 6The schematic diagram illustrates the structural schematic of a computer system of an electronic device according to some embodiments of the present disclosure.

[0029] Figure 7 A schematic diagram of a computer-readable storage medium according to some embodiments of the present disclosure is shown.

[0030] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0032] Furthermore, the accompanying drawings are for illustrative purposes only and are not necessarily drawn to scale. The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0033] In this example embodiment, a boot-up display method is first provided. This boot-up display method can be applied to electronic devices, which refer to computing devices equipped with a central processing unit (CPU), memory, storage media, operating system, and graphics display output capabilities. The operating system can be a Linux system, or other embedded or general-purpose operating systems that support multi-layer display architectures and early graphics output capabilities, such as FreeBSD, Zephyr, QNX, Windows IoT Core, Android (based on the Linux kernel but with an independent graphics stack), and customized real-time operating systems (RTOS) that support UEFI Graphics Output Protocol (GOP) and hardware overlay layers, etc., and is not limited thereto.

[0034] For example, electronic devices can be various computing devices with graphics display capabilities and operating system startup management functions, including but not limited to servers, desktop computers, laptops, embedded devices (such as smart cameras, POS machines, medical monitors or IoT gateways), industrial control terminals, in-vehicle infotainment systems, smart IoT terminals, personal computers, laptops, and dedicated hardware devices with Direct Rendering Manager (DRM) graphics subsystems and kernel log access capabilities.

[0035] Figure 1 The schematic diagram illustrates a power-on display method according to some embodiments of the present disclosure. (See reference...) Figure 1 As shown, the power-on display method may include the following steps: Step S110: In response to the detection of a power-on command, obtain the power-on content and startup log information. The startup log information is generated during the power-on process of the electronic device. Step S120: Load the first layer of the screen onto the screen of the electronic device. The first layer of the screen displays the power-on content. Step S130: Load the second layer of the screen in the target area of ​​the screen. The second layer of the screen displays startup log information and is overlaid on the first layer of the screen.

[0036] According to the power-on display method in this example embodiment, in response to detecting a power-on command, power-on content and startup log information are obtained. The startup log information is generated during the power-on process of the electronic device. By loading a first layer of screen on the screen of the electronic device, which displays the power-on content, and simultaneously loading a second layer of screen in the target area of ​​the screen, which displays the startup log information, and the second layer of screen overlays the first layer of screen, the power-on content and startup log information are respectively carried in two independent layers of screen. Visual collaborative display is achieved through spatial layout (target area) and hierarchical relationship (overlay), so that the power-on content can be displayed in the first layer of screen without interruption, and the startup log information is overlaid in the target area of ​​the screen through the second layer of screen. This effectively solves the conflict problem of startup log information and power-on content in display resources, and realizes the non-intrusive coexistence and synchronous visualization of startup log information and power-on content throughout the entire power-on process.

[0037] Furthermore, even in scenarios without a serial port connection or where remote debugging is not possible, the aforementioned boot display method can still present system boot log information intuitively and continuously on the local monitor. Since the boot log is output through an independent second-layer screen (corresponding to the target overlay layer) and does not rely on the framebuffer console switching mechanism, there will be no black screen or log context loss issues when the graphics subsystem switches from the early eFIFB stage to DRM mode. This significantly improves the observability and location efficiency of faults in the early boot stages, such as kernel initialization and driver loading.

[0038] Meanwhile, by utilizing hardware overlay layers to output boot log information during the boot process to the screen, the boot log information can be presented independently in the second layer of the screen. This avoids occupying or interfering with the display content and rendering process of the main layer (such as brand logos, boot animations, etc.), ensuring the integrity and smoothness of the main visual experience. Furthermore, it can visually present continuous and uninterrupted boot log information. From the early kernel initialization phase until the graphics session is established, the boot log information is constantly updated in real time in the target area. This avoids log interruptions, black screens, or content loss caused by frame buffer switching, console switching, or graphics subsystem takeover, significantly improving the observability of the system boot process and the efficiency of fault diagnosis.

[0039] The boot-up display method in this example embodiment will be further explained below.

[0040] In step S110, in response to the detection of a power-on command, the power-on content and startup log information are obtained. The startup log information is generated during the power-on process of the electronic device.

[0041] The power-on command is a control signal that triggers an electronic device to enter the operating system initialization process from a power-off or hibernation state. This power-on command can be triggered in various ways, including but not limited to: a user pressing the power button, a power-on command sent by a remote management controller, a timed wake-up event, a watchdog reset signal, or a virtual machine startup request issued by the virtualization platform.

[0042] Boot content refers to the visual content preset before the operating system kernel is fully initialized and displayed for boot-up purposes. This can include, for example, brand logos, boot animations, or progress indicators, and is not limited to these.

[0043] In some embodiments, the boot content may be a static image (such as a brand logo in BMP or PNG format). In other embodiments, the boot content may also be a dynamic video sequence or a simple animation drawn based on a framebuffer. The boot content may be loaded and output to the display device by a bootloader (such as U-Boot or GRUB) or an early initialization module (such as a display service in initramfs).

[0044] Boot log information refers to text-based debugging and status information generated by the kernel and early system services during the boot process of an electronic device.

[0045] Specifically, the startup log information comes from the kernel's print log buffer, and its content includes, but is not limited to: kernel version information, hardware detection results, driver loading status, file system mounting process, service startup logs, and error or warning messages. In Linux systems, this log buffer can exist in kernel memory as a circular buffer, and the variable name can be log_buf.

[0046] In some embodiments, in response to detecting a power-on command, power-on content and startup log information can be obtained synchronously or asynchronously.

[0047] In some embodiments, in response to detecting a boot command, boot content can be obtained, and the kernel space can be directly accessed to obtain boot log information.

[0048] It directly accesses the kernel space to obtain boot log information without relying on user-space file system mounting or log daemons (such as rsyslogd or systemd-journald), thus ensuring that complete logs can be obtained in the very early stages of boot (such as during the execution of initramfs).

[0049] In other embodiments, the boot log information may also include output from the firmware layer, such as UEFI Shell (Unified Extensible Firmware Interface Shell) command echoes, Advanced Configuration and Power Interface (ACPI) method execution logs, or Trusted Platform Module (TPM) metric events. This information can be captured by kernel boot parameters such as efi=debug and acpi.debug_layer and uniformly imported into the kernel log buffer.

[0050] In other embodiments, if the serial port console or early frame buffer console is enabled, the relevant output information can also be synchronously recorded in the startup log information.

[0051] Understandably, startup log information has the characteristics of time sequence, continuity and completeness, and can comprehensively reflect the operating status of each component in the startup chain of electronic devices. It is a key basis for fault diagnosis, performance analysis and security audit.

[0052] In step S120, a first layer of screen is loaded onto the screen of the electronic device, and the first layer of screen displays the power-on content.

[0053] Among them, the screen refers to the physical or logical display terminal of an electronic device used to output visual information.

[0054] In some embodiments, the screen may be a liquid crystal display (LCD), an organic light-emitting diode (OLED) panel, a micro-LED display, or an electronic paper (E-Ink) device.

[0055] In other embodiments, the screen may also be a projector, a head-mounted display, or a virtual display window mapped via a remote desktop protocol.

[0056] In other embodiments, the screen may be connected via a standard video interface, including but not limited to a high-definition multimedia interface, DisplayPort, embedded DisplayPort (eDP), mobile industry processor interface display serial interface, or low-voltage differential signal bus, etc.

[0057] The first layer of the screen refers to the independent layer in the display controller hardware architecture used to carry the boot content. It can be understood that in the graphics subsystem, based on the kernel display framework of the Direct Render Manager, the display engine (Cathode Ray Tube Controller, CRTC) can support multiple hardware layers, including the primary plane, overlay plane, and cursor plane, etc.

[0058] In some embodiments, the first layer of the image can be the main layer. In other embodiments, the first layer can be an overlay layer or a cursor layer, while the main layer can present other main visual content.

[0059] For example, the first layer is the main layer, which is a required layer for the main display output of the screen and is activated by default when the system starts up; this first layer can cover the entire screen resolution area.

[0060] In some embodiments, the first layer of the screen can be configured through the atomic commit mechanism of the Kernel ModeSetting (KMS) of the direct rendering manager, so that the framebuffer object containing the boot content is bound to the first layer, and the boot content is presented in the first layer of the screen.

[0061] In other embodiments, if the system has not yet completed the initialization of the direct rendering manager subsystem, the first layer of the image may be provided by an early framebuffer driver, such as a simple framebuffer or a unified extensible firmware interface framebuffer.

[0062] In other embodiments, the first layer can be pre-configured during the firmware stage (e.g., via the Unified Extensible Firmware Interface Graphics Output Protocol, UEFI GOP) so that the boot content is visible before the operating system loads.

[0063] Specifically, the display resources required for the first layer of the image can be configured, activated, and associated with the display engine, and the first layer of the image can be loaded onto the screen through the display engine.

[0064] In some embodiments, if the boot content is a static image, its header information is parsed, and then the RGB pixel data is copied line by line to the frame buffer address. In other embodiments, if the system supports hardware 2D acceleration (such as the GPU BLIT engine), block transfer operations are triggered through register programming to improve rendering efficiency. In still other embodiments, if the boot content contains transparent areas, alpha blending calculations are required, or a semi-transparent effect is achieved by relying on the layer's own global alpha attribute.

[0065] In some embodiments, during the boot process, boot content is displayed in a designated area of ​​the first layer screen. This designated area can be the center area, edge area, or other designated area of ​​the first layer screen, and it may differ from the target area.

[0066] Understandably, by limiting the loading and presentation of boot content to the first layer of the screen, the system ensures that the boot content is output throughout the boot process, providing users with a consistent brand experience and system status awareness.

[0067] In step S130, a second layer of the screen is loaded in the target area of ​​the screen. The second layer of the screen displays startup log information and is overlaid on the first layer of the screen.

[0068] The target area refers to a pre-specified or dynamically calculated local display area on the screen, which is used to carry the second layer of the image.

[0069] In some embodiments, the target area may be the lower right corner, upper left corner, or other fixed corner area of ​​the screen.

[0070] In other embodiments, the location and size of the target region can be dynamically specified by system configuration files or firmware parameters.

[0071] In other embodiments, the target area can also be adaptively adjusted according to the screen resolution, for example, allocating a 320×240 pixel area on a 4K screen resolution and a 240×180 pixel area on a 1080p screen to maintain a consistent ratio.

[0072] The second layer of the display refers to the second layer of the screen used to carry overlay content within the display controller hardware architecture. It can be understood that in a graphics subsystem based on a direct rendering manager, the display engine can support multiple hardware layers, including one or more overlay layers in addition to the main layer. The second layer of the display corresponds to one of these overlay layers.

[0073] The second layer image can have the following technical features: it can be enabled, disabled, or have its attributes configured independently of the main layer; it can be specified at any position and size on the screen; and it can be automatically overlaid with the main layer image along the Z-axis during the hardware compositing stage without the need for software mixing.

[0074] In some embodiments, the second layer image uses a pixel format that supports alpha channels, so that the second layer image covers the first layer image in a semi-transparent or opaque manner.

[0075] The alpha channel refers to the additional data component in pixel data used to represent the opacity of that pixel. In pixel formats with alpha channels (such as ARGB8888), each pixel can consist of four components: Alpha (A), Red (R), Green (G), and Blue (B). The Alpha channel, also known as the alpha channel, controls the degree of transparency of the pixel.

[0076] When the alpha channel value of the second layer is greater than the first threshold and less than the second threshold, the second layer overlays the first layer in a semi-transparent manner; when the alpha channel value of the second layer is the second threshold, the second layer overlays the first layer in an opaque manner. The first threshold is less than the second threshold.

[0077] For example, the alpha channel is set to Alpha, and the alpha value is between 0 and 255, where 0 is the first threshold and 255 is the second threshold. When the alpha value of the second layer is 0, the pixels are completely transparent, meaning the second layer is completely transparent, and the underlying first layer can be fully visible. When the alpha value of the second layer is 255, the pixels are completely opaque, meaning the second layer is opaque overlaid on the first layer. When the alpha value of the second layer is greater than 0 and less than 255, the pixels are semi-transparent, meaning the second layer is semi-transparent overlaid on the first layer, achieving visual blending with the underlying layers.

[0078] Understandably, the alpha channel enables images or layers to achieve visual effects such as non-rectangular display, fade-in / fade-out, and overlay during hardware or software compositing. It is the key technological foundation for achieving a second layer of image overlaid on the main layer in a semi-transparent manner.

[0079] The process is automatically completed by the display controller during the hardware compositing stage, eliminating the need for additional alpha blending calculations in software. This reduces system resource consumption while ensuring the real-time performance and stability of the overlay effect. By employing a pixel format that supports alpha channels, the second layer provides effective debugging information while avoiding visual interference with the main layer (such as brand logos and boot animations), significantly improving the human-computer interaction experience and system observability during the boot phase.

[0080] In some embodiments, the size of the second layer image is smaller than the size of the first layer image.

[0081] For example, the width and height of the second layer image do not exceed 50% of the screen resolution. For example, the size of the second layer image may include 320×240 pixels, 240×180 pixels or 160×120 pixels, and the specific values ​​can be adaptively scaled according to the total screen resolution.

[0082] In some embodiments, the size of the second layer screen can be a fixed value set by system configuration parameters or firmware to ensure a consistent log display ratio across different devices. In other embodiments, the size of the second layer screen can also be dynamically adjusted according to the amount of startup log information, but it always remains smaller than the first layer screen.

[0083] In some embodiments, the second layer screen can be configured via the atomic commit interface set by the direct rendering manager kernel mode to bind a framebuffer object containing startup log information to the second layer, so that the startup log information is displayed in the second layer screen.

[0084] In other embodiments, if multiple overlay layers are available, an appropriate log display layer can be selected as the second layer based on the layer's capabilities.

[0085] In other embodiments, when the hardware does not support independent overlay layers, the second layer can also be displayed as a software composition window.

[0086] In some embodiments, a dot matrix character set (such as an 8×16 or 16×32 pixel ASCII character set) can be built in to convert startup log information into pixel data by looking up the table character by character.

[0087] In other embodiments, the second layer screen can support a scrolling display mechanism. When the number of lines of startup log information exceeds the height of the target area, the startup log information is automatically scrolled upwards in the target area and the oldest line is erased.

[0088] In other embodiments, color differentiation may also be supported, for example, error messages are displayed in red, warnings in yellow, and general information in white to improve readability, but this is not the only one.

[0089] During the hardware rendering stage, the content of the second layer is positioned in front of the first layer along the Z-axis, creating a visual overlay effect where the second layer overlaps the first. It's understandable that, since the two layers are managed independently by the hardware, the boot content of the first layer is unaffected by updates to the second layer; both can coexist without interference.

[0090] In some embodiments, the overlay order is controlled by the layer Z-order attribute, which ensures that the Z-order of the second layer is higher than that of the first layer. In other embodiments, if multiple overlay layers are used, the cursor layer can be further set to be on the top layer, forming a three-layer structure of cursor-logo-main screen.

[0091] Understandably, by limiting the startup log information to the second layer of the screen and overlaying it in the target area, real-time visualization of underlying debugging information is achieved while avoiding obscuring or interrupting the main boot content. This design fully utilizes the multi-layer hardware capabilities of the display controller, solving the technical bottleneck of mutual exclusion between logs and the main screen in traditional framebuffered console solutions, and providing users with a boot display solution that balances brand experience and system observability.

[0092] In some embodiments, displaying startup log information in the second layer screen includes: acquiring new startup log information at a specified period, or displaying new startup log information in the second layer screen when new startup log information is generated during the power-on and startup process of the electronic device.

[0093] The specified period refers to the time interval used to periodically poll and obtain new startup log information.

[0094] In some implementations, startup log information that has not yet been displayed in the log buffer can be read by polling at specified intervals (e.g., every 100 milliseconds or 200 milliseconds), and then rendered to the second-layer screen. In other implementations, when the kernel logging subsystem generates new startup log information, a log refresh operation is triggered through a callback function or the kernel notification chain, and the new startup log information is presented in the second-layer screen.

[0095] When presenting new startup log information, the new startup log information can be parsed and formatted, and then rendered into pixel data based on the built-in character table and written to the corresponding location in the target memory area.

[0096] If the number of new startup log lines exceeds the target area height of the second layer screen, a scrolling operation can be performed. Specifically, the existing content in the second layer screen can be moved up one line, the last line area can be cleared, and new logs can be written at the bottom, thus keeping the latest few lines of logs always visible. In some embodiments, the scrolling process uses a double buffering mechanism to avoid screen tearing. In other embodiments, color-coding by log level (e.g., red for errors, yellow for warnings) is supported to improve readability.

[0097] Understandably, dynamically acquiring and presenting new startup log information through periodic polling or event triggering ensures that the content of the second-layer screen remains synchronized with the actual system startup state, avoiding the information lag issues caused by static snapshots. This mechanism achieves continuous, smooth, and low-latency visualization of startup logs without relying on complete user-space services, significantly enhancing the system's observability and fault diagnosis capabilities in the early startup phase.

[0098] The contents of steps S110 to S130 will be described in detail below.

[0099] In an example embodiment of this disclosure, such as Figure 2 As shown, loading a second layer of content into a target area of ​​the screen can be achieved through the following steps, which may include: Step S210: Determine the target overlay layer from one or more candidate overlay layers.

[0100] In this context, a candidate overlay layer refers to one or more candidate hardware layer resources supported by the display controller hardware that can be used for rendering overlaid content. In a graphics subsystem based on a direct rendering manager, the display engine can provide multiple overlay layers, each with independent attribute configuration capabilities, including position, size, pixel format, rotation, scaling, and transparency control.

[0101] In some embodiments, the number of candidate overlay layers is two or more, for example, one for video playback, one for user interface controls, and another can be reserved for debugging or system information display.

[0102] In other embodiments, the capabilities of the candidate overlay layers differ. Some candidate overlay layers may only support specific pixel formats (such as YUV format), while others may support ARGB format with an alpha channel, suitable for semi-transparent overlay of text logs.

[0103] In other embodiments, the target overlay layer can be determined from one or more available candidate overlay layers. It is understood that some candidate overlay layers may already be used by other system services (such as Plymouth animations or security alert windows), therefore it is necessary to dynamically query their availability.

[0104] In some embodiments, a target overlay layer with the characteristics required to present startup log information can be determined based on the layer capabilities of each candidate overlay layer. For example, since startup log information is presented as text with a transparent background, a target overlay layer that supports ARGB8888 pixel format, has global alpha control, and is not currently in use can be selected from among the candidate overlay layers.

[0105] In other embodiments, a preset strategy can be used to determine the target overlay layer from one or more candidate overlay layers. For example, the available overlay layer with the smallest number can be used, or a dedicated log layer can be specified by the firmware through a device tree or ACPI table.

[0106] In other embodiments, if the system supports a layer priority mechanism, the target overlay layer is assigned a Z-order priority that is higher than that of ordinary applications but lower than that of security alarms, so as to ensure the visibility of startup log information while avoiding interference with key prompts.

[0107] Step S220: Bind the startup log information to the target overlay layer, and load the second layer of the target overlay layer in the target area of ​​the screen. The second layer displays the startup log information bound to the target overlay layer.

[0108] It is understandable that establishing a logical connection between the rendering output of the startup log and the target overlay layer ensures that the log content of the startup log information can be correctly displayed through the second layer of the target overlay layer.

[0109] In some embodiments, a mapping relationship between startup log information and target overlay layer can be established, and the startup log information can be presented in the second layer screen according to the mapping relationship when the second layer screen is loaded.

[0110] In other embodiments, binding startup log information to the target overlay layer includes: rendering startup log information to the target memory region; registering the target memory region carrying startup log information as a framebuffer object managed by the rendering manager, and generating a corresponding framebuffer object identifier; and binding the framebuffer object identifier to the target overlay layer.

[0111] The target memory region refers to a block of system memory used to store the rendered startup log image data. This target memory region can be a physically contiguous block of memory or a virtual contiguous region mapped by the Memory Management Unit (MMU). The contents of this target memory region can be organized in the form of a bitmap, with pixels arranged in rows, and the format is consistent with the pixel format supported by the subsequently bound layers (such as ARGB8888, XRGB8888, etc.).

[0112] In some embodiments, rendering startup log information to a target memory region includes: requesting a target memory region; obtaining a writable virtual address of the target memory region by memory mapping; and rendering startup log information to the target memory region where the writable virtual address is located.

[0113] In some implementations, a physically contiguous memory region can be requested through kernel memory allocation interfaces (such as alloc_pages or dma_alloc_coherent) to meet the display controller's requirement for physical address contiguousness.

[0114] In other implementations, if the system supports an IOMMU (Input-Output Memory Management Unit) or SMMU (System Memory Management Unit), non-contiguous physical pages can be requested and mapped to contiguous device virtual addresses through page tables to obtain the target memory region, thereby improving memory utilization.

[0115] In some embodiments, when requesting a target memory region to carry startup log information, the actual output resolution of the current display controller can be queried. For example, the actual output resolution of the current display controller can be used as a reference benchmark for the second layer screen. If the target area is a partial display (e.g., 320×240), the target memory region is requested according to a preset size, and hardware scaling is implemented through the source rectangle (src_rect) and target rectangle (dst_rect) parameters when submitted to the overlay layer to ensure that the log content adapts to the target screen area. Alternatively, when the display engine is not yet activated (e.g., in the early UEFI stage), the target memory region is requested using a default security resolution (e.g., 1024×768), and dynamically adjusted after DRM is ready.

[0116] In other embodiments, the size of the target memory area can be pre-calculated based on the resolution and pixel format of the target screen area. For example, for a log display area with a resolution of 320×240 and a pixel format of ARGB8888 (4 bytes per pixel), the required memory size is 320×240×4=307,200 bytes, with additional alignment padding reserved to adapt to the hardware access granularity.

[0117] After requesting the target memory region, a writable virtual address of the target memory region can be obtained through memory mapping (MMAP). This allows the CPU to directly write the rendered startup log information into the target memory region at the writable virtual address, improving graphics rendering efficiency and simplifying the memory management process.

[0118] The target memory region can be reserved by the kernel through the Contiguous Memory Allocator (CMA) to ensure its physical address contiguousness, facilitating direct access by the display controller. In other embodiments, the target memory region can also be dynamically allocated through standard memory allocation interfaces (such as kmalloc or alloc_pages) and used by the graphics subsystem in conjunction with I / O memory mapping mechanisms. In other embodiments, the target memory region can be determined in other ways, such as directly determining the target memory region from shared main memory, allowing it to be accessed by both the CPU and GPU (Graphics Processing Unit) without additional copying.

[0119] It is understandable that by requesting the target memory region, establishing its writable virtual address mapping, and directly rendering the startup log information in that address space, efficient conversion from raw log text to bitmap data and in-situ memory writing can be achieved, avoiding intermediate copy overhead, while ensuring seamless connection with subsequent framebuffer object registration and layer binding processes.

[0120] In other embodiments, rendering the startup log information to the target memory area includes: parsing the log text stored in the kernel line by line to obtain the startup log information; and rendering the startup log information to the target memory area according to the built-in character set.

[0121] The kernel-stored log text refers to the raw log data generated by the operating system kernel and cached in kernel memory during the boot process of an electronic device. This log data can be stored in the form of a ring buffer, such as the log_buf buffer written by the printk mechanism in Linux systems. The contents of this buffer can include complete boot process information, such as hardware initialization status, driver loading results, file system mount records, and various debugging, warning, or error messages.

[0122] A character bitmap table is a character bitmap database pre-embedded in system firmware or kernel image, used to convert each character in the ASCII or extended character set into a corresponding pixel pattern.

[0123] In some embodiments, the character table can adopt a fixed-width bitmap format, such as 8×16, 16×32, or 12×24 pixels, with each character corresponding to a two-dimensional bitmap, where each bit represents whether a pixel is lit. In other embodiments, the character table can be compiled into the kernel as a read-only data segment (.rodata), requiring no external file dependencies and ensuring usability in the early stages before the root filesystem is mounted. In still other embodiments, the character table can also support multi-color mapping, for example, rendering error-level log characters as red pixels and normal information as white, achieved by adding color channels during table lookups.

[0124] Specifically, the kernel-stored log text (such as the kernel printk buffer or a copy of the kernel log) is obtained, each line of log text to be displayed is traversed to obtain the startup log information, and the startup log information is queried character by character from the character table to obtain its bitmap data. The bitmap is then written to the corresponding position in the target memory area by column or by row.

[0125] For example, in the target memory area, each pixel is usually represented in ARGB8888 or XRGB8888 format. During rendering, the "1" of the font bitmap is mapped to the foreground color (including the alpha channel), and the "0" is mapped to the background transparency or black. When rendering the startup log information to the target memory area, it can start from the top left corner of the target area and be laid out in rows. The height of each row is equal to the height of the font, and the row spacing is configurable.

[0126] In other example embodiments, other rendering methods can also be used, such as supporting automatic line wrapping and truncation processing, truncating the excess part or enabling horizontal scrolling when the log line length exceeds the target area width; or, to improve efficiency, rendering operations can be performed directly in kernel space to avoid context switching overhead, and write-combining memory properties can be used to accelerate video memory writing.

[0127] Understandably, by parsing the kernel log text line by line and rendering it directly as a bitmap based on the built-in character set, it is possible to efficiently and reliably visualize and output the boot log to the target memory area in an environment without file system or font library dependencies.

[0128] Furthermore, in some embodiments, rendering the startup log information to the target memory region includes: allocating the target memory region; obtaining the writable virtual address of the target memory region through memory mapping; parsing the log text stored in the kernel line by line to obtain the startup log information; and rendering the startup log information to the target memory region where the writable virtual address is located according to the built-in character set. It should be noted that the specific implementation and related explanations of each step in this embodiment are consistent with the above embodiments, and will not be repeated here.

[0129] The rendering manager is a core component in the operating system kernel responsible for managing graphics display resources, coordinating framebuffer allocation, and layer compositing. In Linux-based operating systems, this rendering manager can be handled by the direct rendering manager subsystem. The direct rendering manager provides a standardized set of kernel interfaces for creating and destroying framebuffer objects, configuring the display engine, managing hardware planes, and setting execution modes.

[0130] A framebuffer object is a logical display resource encapsulated and managed by the rendering manager. Its underlying layer corresponds to a memory area containing complete image data (i.e., the target memory area), and it comes with metadata descriptions, including attributes such as width, height, pixel format, scan line spacing, and color space.

[0131] A framebuffer object identifier is an identifier used to uniquely identify a framebuffer object. Within the rendering manager framework, this framebuffer object identifier can be fb_id, a 32-bit unsigned integer.

[0132] After rendering the startup log information to the target memory region, you can submit the target memory region descriptor (such as physical address, width, height, pixel format, etc.) containing the startup log information to the rendering manager by calling the API interface provided by the rendering manager (such as the drmModeAddFB or drmModeAddFB2 function in the rendering manager), so that it can recognize and encapsulate it into a framebuffer object (FBO).

[0133] During this process, the rendering manager verifies the validity of the input parameters, such as checking whether the pixel format is supported by the hardware and whether the size exceeds the capabilities of the display controller, and returns a unique framebuffer object identifier (fb_id).

[0134] Binding the framebuffer object identifier to the target overlay layer ensures the correct display of startup log information on the screen. This process involves updating the configuration of the target overlay layer's properties, specifically assigning the previously obtained framebuffer object identifier to the relevant attribute fields of the target overlay layer, and setting appropriate display position, size, and other visual effect parameters (such as rotation angle and transparency).

[0135] In some embodiments, to enhance the system's flexibility and responsiveness, a layer state caching mechanism can be introduced. This means that after each modification of a layer attribute, it is not immediately committed to the hardware, but is first saved in a local cache. Once all relevant attribute configurations are completed, it is committed in a unified manner, thereby reducing unnecessary hardware interactions and improving overall performance.

[0136] Understandably, by performing memory rendering of startup log information, registration of framebuffer objects, and binding of framebuffer object identifiers with target overlay layers, an efficient and stable boot log display mechanism is constructed. This mechanism not only fully utilizes the multi-layer processing capabilities of the display hardware, but also enhances the system's adaptability to different hardware platforms and application scenarios through modular operation steps, effectively ensuring the accurate presentation of startup log information.

[0137] Load the second layer of the target overlay in the target area of ​​the screen, that is, submit the target overlay that has been bound to the display hardware and activate the display.

[0138] In some embodiments, the atomic submission mechanism of the Kernel Mode Setting (KMS) of the rendering manager can be used to load the second layer of the target overlay in the target area of ​​the screen, and submit the complete set of attributes containing the configuration of the target overlay to the display engine at once, ensuring the atomicity and timing consistency of the display state switching.

[0139] In other embodiments, if the system is in the early startup phase and atomic mode settings are not yet enabled, layer loading can be completed through a traditional non-atomic KMS interface (such as drmModeSetPlane).

[0140] In other embodiments, the loading operation may trigger a display controller interrupt, notifying the hardware to immediately refresh the next frame so that the startup log information is displayed on the screen in real time.

[0141] In some embodiments, a degradation strategy can be automatically triggered when no available overlay layer is detected, DRM device initialization fails, or framebuffer creation anomalies or layer binding timeouts occur. In some embodiments, a fallback to a traditional framebuffer console can be implemented, outputting startup log information in plain text to the main display area. In other embodiments, even if the log cannot be displayed, startup log information can be written to persistent storage (such as / var / log / boot.log or efivars) for subsequent diagnostics. In still other embodiments, error codes can be logged and hardware alarms can be issued via LEDs or buzzers. This mechanism ensures that debugging information is not lost and basic observability is maintained across various hardware platforms or in abnormal scenarios.

[0142] Understandably, by dynamically selecting and binding the target overlay layer from multiple candidate overlay layers, not only can the flexibility of layer resource utilization be improved, but also the differences in layer capabilities of different hardware platforms can be adapted to ensure that startup log information can be reliably and efficiently overlaid on the main boot content on various electronic devices, while avoiding resource conflicts with other graphics applications.

[0143] Furthermore, by using the target overlay layer in the candidate overlay layers to carry the second layer image, instead of occupying the primary plane or the global frame buffer, interference with the first layer image (such as the boot animation or brand logo) can be effectively avoided.

[0144] In some embodiments, such as Figure 3 The diagram illustrates another method for powering on and displaying an electronic device. Step S310 initiates the initialization process of the graphics subsystem. Initialization may include loading kernel modules, resolving the device tree or ACPI configuration, detecting available display devices, and initializing components related to the direct rendering manager.

[0145] Step S320 is executed to detect the rendering manager. Specifically, it scans the currently connected graphics hardware to determine whether the graphics hardware has DRM driver support. For example, in Linux systems, integrated graphics cards, discrete GPUs, and embedded display controllers all provide DRM interfaces.

[0146] Execute step S330 to determine if an overlay layer is available. This can be determined by querying the render manager's device properties (such as the plane type returned by the drmModeGetPlane interface).

[0147] If the determination is negative, proceed to step S340 to retry or roll back. If the determination is positive, select the target overlay layer and proceed to step S350 to allocate the target memory region.

[0148] Execute step S360 to render the startup log information to the target memory area.

[0149] In step S370, the target memory region carrying the startup log information is submitted to the target overlay layer. That is, the target memory region carrying the startup log information is registered as a framebuffer object managed by the rendering manager, a corresponding framebuffer object identifier is generated, and the framebuffer object identifier is bound to the target overlay layer. This allows the second layer of the target overlay layer to be loaded in the target area of ​​the screen, and the startup log information bound to the target overlay layer is displayed in the second layer.

[0150] In one example embodiment of this disclosure, the method further includes: after the electronic device is powered on and started up, closing the second layer screen and releasing the resources of the second layer screen; and displaying the desktop in the first layer screen.

[0151] The resources of the second layer screen refer to the collection of various software and hardware system resources allocated and used to realize the creation, display and management of the second layer screen.

[0152] The resources of the second layer may include, but are not limited to, the video memory buffer (i.e., the framebuffer memory area) allocated to the layer, the framebuffer object and its corresponding framebuffer object identifier (fb_id) generated by the rendering manager, the hardware overlay layer handle occupied by the layer in the display controller, the display attribute configuration associated with the layer (including position coordinates, size, pixel format, transparency, Z-order, etc.), and at least one of the following: mapped virtual address space and kernel or user space rendering context.

[0153] Specifically, before the operating system is ready to display the user interface, the second-layer screen used to display startup log information will be automatically turned off. At the same time, corresponding resource cleanup work can be performed, including but not limited to releasing video memory, stopping related rendering processes, and disconnecting any hardware acceleration services related to the second layer, thereby reducing the system's operating load and providing more ample resource space for subsequent applications.

[0154] The desktop is displayed on the first layer of the screen, overlaying the boot content. This means the main visual area transitions from initial content such as brand logos, onboarding animations, or startup progress to the user's personalized desktop, marking the formal end of the startup process and the beginning of normal use. This process not only ensures a consistent and seamless user experience but also enhances system responsiveness and stability through a well-designed resource allocation strategy.

[0155] Furthermore, in some embodiments, the working state of the electronic device can be determined. If the working state of the electronic device is a normal working state, then after the electronic device is powered on and started up, the second layer screen is turned off and the resources of the second layer screen are released; the desktop is displayed in the first layer screen.

[0156] The "normal working state" refers to the working state of electronic devices when used by ordinary consumers. For example, when using electronic devices such as desktop computers, ordinary consumers usually close the second-layer screen immediately after the electronic device is powered on and started up, in order to avoid making ordinary consumers think that the screen of the electronic device is malfunctioning.

[0157] In an example embodiment of this disclosure, the method further includes: displaying the desktop in the first layer screen after the electronic device has been powered on and started; displaying the second layer screen in the target area of ​​the screen using a lease isolation method, wherein the second layer screen displays startup log information.

[0158] Once the electronic device completes operating system kernel initialization, user space service loading, and graphical session establishment, the boot process can be considered complete, and the content of the first layer screen is switched from the boot screen to the user desktop environment. This desktop may include standard graphical elements such as window manager interface, icons, taskbar, and wallpaper, and is output by a display compositor (such as Wayland compositor or X Server) through the primary plane, serving as the main visual carrier for user interaction.

[0159] Meanwhile, to meet the needs of operation and maintenance debugging or security auditing, it is possible to retain the display of the second layer after startup, but its presentation adopts a lease-based isolation mechanism. Lease-based isolation refers to temporarily leasing specific display hardware resources (including the target overlay layer, CRTC, connector, and frame buffer objects) from the main graphics session through the resource lease function of the graphics subsystem, and entrusting them to an independent trusted log display process for exclusive use, thereby achieving resource isolation and access control from the desktop environment.

[0160] It is understandable that when loading the second layer, access to the DRM device node (such as / dev / dri / card0) is required. In some embodiments, user-space programs (such as the debug daemon in initramfs) can run as root and obtain the DRM master device file descriptor through the open() system call, thereby performing framebuffer registration and layer binding. In other embodiments, if a lease isolation (drm-lease) mechanism is used to achieve resource isolation, a privileged process (such as systemd) needs to create a lease context and securely pass the generated lease file descriptor (lease_fd) to the log display agent; the recipient obtains exclusive access to the target overlay layer, display engine, and connector through this lease file descriptor without requiring global DRM privileges, thereby improving system security. All operations must be authorized through kernel capability verification (such as CAP_SYS_ADMIN) or SELinux policies to prevent unauthorized processes from tampering with the display content.

[0161] In some embodiments, lease isolation can be implemented based on the Atomic Modesetting Lease mechanism of the rendering manager subsystem. Specifically, the kernel authorizes a privileged debug agent process (such as systemd-debug-shell or a dedicated logging daemon) to create a lease context that includes exclusive access to the target overlay layer and related display resources; the desktop compositor cannot modify or overwrite the layer content covered by the lease, ensuring the continuous visibility and tamper-proof nature of startup log information.

[0162] In other embodiments, the lease validity period can be configured to a fixed duration (e.g., continuously displayed for 60 seconds after startup), or it can be manually closed by the user, or automatically terminated when a security policy change is detected (e.g., entering production mode). After the lease expires or is actively released, the relevant layer resources are automatically returned to the main graphics session, and the second layer screen is subsequently closed, avoiding long-term occupation of hardware resources.

[0163] In other embodiments, the lease isolation method can also prevent ordinary applications from interfering with or obscuring the second layer of the screen through graphics APIs (such as OpenGL, Vulkan or EGL), fundamentally solving the problem of log information being overwritten due to window level conflicts in traditional software overlay schemes.

[0164] Furthermore, in some embodiments, the working state of the electronic device can be determined. If the working state of the electronic device is a test state or an operation and maintenance state, the desktop is displayed in the first layer screen after the electronic device is powered on and started. The second layer screen is displayed in the target area of ​​the screen using a lease isolation method, and the second layer screen displays startup log information.

[0165] Among them, "test status" refers to the working status of the electronic device when testers perform tests. "Maintenance status" refers to the working status of the electronic device when maintenance personnel perform maintenance.

[0166] For example, when testers or maintenance personnel are testing or maintaining electronic devices such as desktop computers, if the electronic device malfunctions during the boot process, a second layer of the screen can still be displayed in the target area after the boot process is completed. This allows testers or maintenance personnel to still obtain boot log information from the second image during the boot process, so as to resolve the malfunction.

[0167] Understandably, by continuing to display the second layer of the screen in the target area under lease isolation after startup, this solution not only ensures the normal presentation of the desktop environment, but also achieves persistent visualization of startup log information under controlled, secure, and isolated conditions. It can be applied to server, industrial control terminal, or safety-critical equipment scenarios that have high requirements for system observability, debugging capabilities, or compliance auditing.

[0168] Furthermore, even after the operating system has entered a graphical session (such as the Xorg or Wayland desktop environment), the independent display of the second layer can still be maintained through the lease-based isolation mechanism. When the startup process is complete or the user does not need to debug information, it is only necessary to close the target overlay layer and release its associated resources to smoothly transition to the normal desktop display without refreshing or rebuilding the entire frame buffer content, thus achieving efficient and low-intrusion visual management of startup logs.

[0169] In some embodiments, such as Figure 4 As shown, another method for booting up and displaying is also provided, applicable to electronic devices. Step S410 executes the Unified Extensible Firmware Interface bootloader, which is responsible for initializing the hardware and loading the operating system kernel.

[0170] In step S420, simple graphics rendering is performed via the UEFI frame buffer driver, such as displaying a startup progress bar or brand logo, to provide basic visual feedback.

[0171] Execute step S430 to switch to direct rendering manager mode, whereby the kernel takes over control of the graphics device, preparing for subsequent advanced graphics features.

[0172] Execute step S440 to display boot content, such as the brand logo or boot animation. This content is output through the main layer and covers the main area of ​​the screen.

[0173] Execute step S450, and at the same time display startup log information in the target area of ​​the screen (such as the lower right corner). This information is output through the target overlay layer to achieve overlay display with the first layer screen.

[0174] Execute step S460. After the system boots up, release the resources occupied by the second layer screen, including video memory, frame buffer objects, and layer handles, to ensure that the resources are effectively reclaimed.

[0175] Execute step S470 to finally display the desktop user interface and complete the entire startup process.

[0176] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0177] Furthermore, in this example embodiment, a power-on display device is also provided, applied to an electronic device. (See reference...) Figure 5 As shown, the power-on display device 500 includes: an information acquisition module 510 and a screen loading module 520. Wherein: Information acquisition module 510 is used to acquire power-on content and startup log information in response to the detection of a power-on command. The startup log information is generated during the power-on process of the electronic device. The screen loading module 520 is used to load a first-layer screen onto the screen of the electronic device, the first-layer screen displaying startup content; and The screen loading module 520 is also used to load a second layer of screen in the target area of ​​the screen. The second layer of screen displays startup log information and is overlaid on the first layer of screen.

[0178] In some example embodiments of this disclosure, based on the foregoing scheme, the screen loading module 520 is configured as follows: Determine the target overlay layer from one or more candidate overlay layers; The startup log information is bound to the target overlay layer, and the second layer of the target overlay layer is loaded in the target area of ​​the screen. The second layer displays the startup log information bound to the target overlay layer.

[0179] In some example embodiments of this disclosure, based on the foregoing scheme, the screen loading module 520 is configured as follows: Render the startup log information to the target memory area; Register the target memory region carrying startup log information as a framebuffer object managed by the rendering manager and generate the corresponding framebuffer object identifier. Bind the framebuffer object identifier to the target overlay layer.

[0180] In some example embodiments of this disclosure, based on the foregoing scheme, the screen loading module 520 is configured as follows: Request the target memory region; Obtain the writable virtual address of the target memory region using memory mapping; The startup log information is rendered to the target memory region where the writable virtual address is located.

[0181] In some example embodiments of this disclosure, based on the foregoing scheme, the screen loading module 520 is configured as follows: The kernel-stored log text is parsed line by line to obtain the startup log information; The startup log information is rendered to the target memory area according to the built-in character set.

[0182] In some example embodiments of this disclosure, based on the foregoing scheme, the screen loading module 520 is configured as follows: New startup log information is retrieved at a specified period, or when new startup log information is generated during the startup process of an electronic device, the new startup log information is displayed in the second layer screen.

[0183] In some example embodiments of this disclosure, based on the aforementioned scheme, the size of the second layer image is smaller than the size of the first layer image.

[0184] In some example embodiments of this disclosure, based on the foregoing scheme, the screen loading module 520 is configured as follows: After the electronic device has finished booting up, close the second layer screen and release its resources. The desktop is displayed in the first layer of the screen.

[0185] In some example embodiments of this disclosure, based on the foregoing scheme, the screen loading module 520 is configured as follows: After the electronic device has finished booting up, the desktop is displayed in the first layer of the screen. The second layer of the screen is displayed in the target area of ​​the screen using a lease isolation method. The second layer of the screen displays startup log information.

[0186] In some example embodiments of this disclosure, based on the aforementioned scheme, the second layer image adopts a pixel format that supports transparency channels, so that the second layer image covers the first layer image in a semi-transparent or opaque manner.

[0187] The specific details of each module of the above power-on display device have been described in detail in the corresponding power-on display method, so they will not be repeated here.

[0188] It should be noted that although several modules or units of the power-on display device have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0189] Furthermore, in an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described power-on display method is also provided.

[0190] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be embodied in the following forms: a completely hardware embodiment, a completely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0191] The following reference Figure 6 To describe an electronic device 600 according to such an embodiment of the present disclosure. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0192] like Figure 6 As shown, the electronic device 600 is manifested in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), and a display unit 640.

[0193] The storage unit stores program code that can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 610 can perform actions such as... Figure 1In step S110, in response to detecting a power-on command, power-on content and startup log information are obtained, and the startup log information is generated during the power-on process of the electronic device; in step S120, a first layer of screen is loaded on the screen of the electronic device, and the power-on content is displayed in the first layer of screen; in step S130, a second layer of screen is loaded in the target area of ​​the screen, and the startup log information is displayed in the second layer of screen, and the second layer of screen covers the first layer of screen.

[0194] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 621 and / or cache memory 622, and may further include read-only memory (ROM) 623.

[0195] Storage unit 620 may also include a program / utility 624 having a set (at least one) of program modules 625, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0196] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0197] Electronic device 600 can also communicate with one or more external devices 670 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. As shown, network adapter 660 communicates with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0198] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0199] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0200] refer to Figure 7 As shown, a program product 700 for implementing the above-described power-on display method according to an embodiment of the present disclosure is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0201] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0202] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0203] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0204] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0205] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0206] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0207] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0208] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for displaying upon power-on startup, characterized in that, Applied to electronic devices, the method includes: In response to the detection of a power-on command, the device acquires power-on content and startup log information, wherein the startup log information is generated during the power-on process of the electronic device; A first layer of screen is loaded onto the screen of the electronic device, the first layer of screen displaying the boot content; and A second layer of screen is loaded in the target area of ​​the screen. The second layer of screen displays the startup log information and is overlaid on the first layer of screen.

2. The power-on display method according to claim 1, characterized in that, Loading the second layer of image in the target area of ​​the screen includes: Determine the target overlay layer from one or more candidate overlay layers; The startup log information is bound to the target overlay layer, and the second layer of the target overlay layer is loaded in the target area of ​​the screen. The second layer displays the startup log information bound to the target overlay layer.

3. The power-on display method according to claim 2, characterized in that, The step of binding the startup log information with the target overlay layer includes: Render the startup log information to the target memory area; Register the target memory region carrying the startup log information as a framebuffer object managed by the rendering manager, and generate a corresponding framebuffer object identifier. Bind the framebuffer object identifier to the target overlay layer.

4. The power-on display method according to claim 3, characterized in that, The step of rendering the startup log information to the target memory region includes: Request the target memory region; Obtain the writable virtual address of the target memory region using memory mapping; The startup log information is rendered to the target memory region where the writable virtual address is located.

5. The power-on display method according to claim 1, characterized in that, The second layer of the screen displays the startup log information, including: New startup log information is obtained at a specified period, or new startup log information is generated during the power-on process of the electronic device, and the new startup log information is displayed in the second layer screen.

6. The power-on display method according to any one of claims 1 to 5, characterized in that, The method further includes: After the electronic device has finished powering on, the second layer screen is turned off and its resources are released. The desktop is displayed in the first layer of the screen.

7. The power-on display method according to any one of claims 1 to 5, characterized in that, The method further includes: After the electronic device has finished powering on, the desktop is displayed in the first layer of the screen; The second layer of the screen is displayed in the target area of ​​the screen using a lease isolation method, and the startup log information is presented in the second layer of the screen.

8. The power-on display method according to any one of claims 1 to 5, characterized in that, The second layer uses a pixel format that supports alpha channels, allowing it to overlay the first layer in a semi-transparent or opaque manner.

9. A power-on display device, characterized in that, Applied to electronic devices, the device includes: The information acquisition module is used to acquire boot content and boot log information in response to the detection of a power-on command, wherein the boot log information is generated during the power-on process of the electronic device; A screen loading module is used to load a first layer of screen onto the screen of the electronic device, the first layer of screen displaying the boot content; and The screen loading module is also used to load a second layer of screen in the target area of ​​the screen. The second layer of screen displays the startup log information and is overlaid on the first layer of screen.

10. An electronic device, characterized in that, include: processor; as well as A memory storing computer-readable instructions that, when executed by the processor, implement the power-on display method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the boot-up display method as described in any one of claims 1 to 8.

Images