Startup processing method, display device, computer device and storage medium
By mounting a boot event monitoring driver and a silent screen activation driver during the kernel layer startup phase, the system detects and responds to boot commands to light up the screen, thus solving the problem of the device screen turning off during silent boot and improving the user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN TCL NEW-TECH CO LTD
- Filing Date
- 2026-01-13
- Publication Date
- 2026-05-12
AI Technical Summary
During the native silent boot process, the device screen remains off for an extended period, unable to respond to external events. This makes it difficult for users to determine the device's status, causing confusion and anxiety, and ultimately reducing the user experience.
During the kernel-level startup phase, a boot event monitoring driver and a silent screen activation driver are mounted to detect boot commands and respond to screen activation, thus achieving silent screen activation.
Enabling the screen to light up promptly during silent power-on enhances the user experience, eliminates user concerns about the device's status, and improves the speed of device interaction.
Smart Images

Figure CN122019002A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of smart home appliances, specifically to a power-on processing method, a display device, a computer device, and a storage medium. Background Technology
[0002] With the rapid development of embedded systems and smart terminal technologies, users have placed higher demands on the human-computer interaction experience of devices, especially in the boot process, where a fast and seamless boot experience has become an industry trend. To address this, the Silent Boot mode has been proposed. This mode deeply customizes the system boot chain (such as the general bootloader, kernel, and Android framework layers) to suppress or block conventional visual and auditory elements during boot, such as brand logos, boot animations, and notification sounds. It aims to present users with a process from pressing the power button to entering the application interface with a black screen or static display, thereby creating a professional and immersive device user experience.
[0003] However, in practical applications, the native silent boot solution has its flaws. Silent boot typically lasts 20 to 30 seconds, during which the device screen remains off, and the system cannot respond to any external events, including requests to light up the screen by pressing the power button, until the core services are loaded. This prolonged period of unresponsive black screen makes it impossible for users to determine whether the device is booting normally, has crashed, or is experiencing other issues, leading to confusion and anxiety, and significantly reducing the user experience. Summary of the Invention
[0004] This application provides a power-on processing method, a display device, a computer device, and a storage medium, which are used to respond to a power-on command during a silent power-on process to achieve silent screen lighting.
[0005] The technical solution adopted by this invention to solve the problem is as follows: In a first aspect, this application provides a power-on processing method, including: When the current boot process is a kernel-level boot process and a silent boot process, the first boot event monitoring driver and the silent screen tapping driver are mounted. Based on the first boot event monitoring driver, the presence of a boot command is detected; When the power-on command is present, in response to the power-on command, the display of the display device is turned on based on the silent screen driver.
[0006] In some embodiments of this application, before detecting the presence of a boot command based on the first boot event monitoring driver, the method further includes: Obtain the first parameter, which indicates that the current boot-up phase is a silent boot phase; Based on this first parameter, the current boot-up phase is determined to be a silent boot phase.
[0007] In some embodiments of this application, the method further includes: The first parameter is generated when the current boot stage is the general boot loading layer boot stage and the current boot stage is the silent boot stage; The first parameter is passed to the kernel layer.
[0008] In some embodiments of this application, the method further includes: When the current boot startup phase is the general boot loading layer startup phase and the current boot startup phase is the silent startup phase, a second parameter is generated, which is used to indicate that the current boot startup phase is the silent startup phase; The second parameter is passed to the power management service layer.
[0009] In some embodiments of this application, the method further includes: When the current boot startup phase is the general boot loading layer startup phase and the current boot startup phase is the silent startup phase, the boot identifier data is loaded and the boot identifier data is stored in the image cache area.
[0010] In some embodiments of this application, after turning on the display of the display device based on the silent screen-on driver in response to the power-on command, the method further includes: Modify the first parameter to the third parameter, and pass the third parameter to the power management service layer. The third parameter is used to indicate that the current power-on startup phase has exited the silent startup phase. Uninstall the silent screen driver.
[0011] In some embodiments of this application, after detecting the presence of a boot command based on the first boot event monitoring driver, the method further includes: When the current boot-up phase is the power management service layer boot-up phase and the current boot-up phase is the silent boot-up phase, start the second boot event monitoring driver; The second boot event monitoring driver detects whether the boot command exists. When the power-on command is present, in response to the power-on command, the display of the display device is turned on based on the silent screen driver.
[0012] In some embodiments of this application, after detecting the presence of the boot command based on the second boot event monitoring driver, the method further includes: When the silent startup phase ends and no power-on command is detected, the silent screen driver is uninstalled and the standby process is executed.
[0013] In some embodiments of this application, after turning on the display of the display device based on the silent screen-on driver in response to the power-on command, the method further includes: Uninstall the silent screen driver.
[0014] In some embodiments of this application, prior to starting the second boot event monitoring driver, the method further includes: Obtain the first parameter and the second parameter, wherein the second parameter is passed from the general boot loader layer to the power management service layer, the first parameter is passed from the kernel layer to the power management server, the second parameter is used to indicate that the current boot stage is a silent boot stage, and the first parameter is used to indicate that the current boot stage is a silent boot stage; Based on the first parameter and the second parameter, the current boot-up phase is determined to be a silent boot phase.
[0015] In some embodiments of this application, after detecting the presence of a boot command based on the first boot event monitoring driver, the method further includes: If the current boot-up phase is the power management service layer boot-up phase and the current boot-up phase has exited the silent boot phase, the normal boot-up process is executed.
[0016] In some embodiments of this application, the method further includes, prior to performing the normal boot process: Obtain the second parameter and the third parameter, wherein the second parameter is passed from the general boot loading layer to the power management service layer, and the third parameter is passed from the kernel layer to the power management server. The second parameter is used to indicate that the current boot stage is a silent boot stage, and the third parameter is used to indicate that the current boot stage has exited the silent boot stage. Based on the second and third parameters, it is determined that the current boot-up phase has exited the silent boot phase.
[0017] In some embodiments of this application, the method further includes: If the current boot-up phase is the power management service layer boot-up phase and the current boot-up phase has exited the silent boot-up phase, uninstall the silent screen driver.
[0018] Secondly, this application provides a display device, comprising: Processor and display; The processor is configured to, when the current boot-up phase is the kernel-level boot phase and the current boot-up phase is a silent boot phase, mount a first boot event monitoring driver and a silent screen-on driver; detect the presence of a boot command based on the first boot event monitoring driver; and, in response to the boot command, turn on the display of the display device based on the silent screen-on driver.
[0019] Thirdly, this application also provides a computer device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the boot process method of any of the first aspects.
[0020] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps of the boot process method of any of the first aspects.
[0021] The beneficial effects of this invention are as follows: By adding a boot event monitoring driver and a silent screen activation driver to the kernel layer boot process, the boot command can be detected based on the newly added boot event monitoring driver when the silent boot process reaches the kernel layer. After the boot command is detected, the screen is turned on based on the silent screen activation driver, thereby realizing screen activation during the silent boot process and improving the user experience. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 This is a flowchart illustrating the native silent boot process; Figure 2 This is a schematic diagram of a silent power-on process provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of an application scenario of the boot-up processing method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the architecture of a display device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of an embodiment of the power-on processing method provided by the present invention; Figure 6A schematic flowchart of an embodiment of the power-on processing method provided in this invention; Figure 7 This is a schematic diagram of one embodiment of the display device provided in this invention. Detailed Implementation
[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0025] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more features.
[0026] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.
[0027] It should be noted that since the method in this application embodiment is executed in a computer device, the processing objects of each computer device exist in the form of data or information, such as time, which is essentially time information. It is understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the computer device can process them. Specific details will not be elaborated here.
[0028] With the rapid development of embedded systems and smart terminal technologies, users have placed higher demands on the human-computer interaction experience of devices, especially in the boot process. A fast and seamless boot experience has become an industry trend. To address this, a Silent Boot mode has been proposed. This mode deeply customizes the system boot chain (such as the general bootloader, kernel, and Android framework layers) to suppress or block conventional visual and auditory elements such as brand logos, boot animations, and notification sounds during the boot process. It aims to present users with a process from pressing the power button to entering the application interface with a black screen or static display, thereby creating a professional and immersive device user experience. Currently, the native silent boot process can be as follows: Figure 1 As shown: The application / system calls the power management silent reboot interface to perform a cold shutdown; then it broadcasts a cold shutdown to shut down the activity management service and package management service; it initiates a silent reboot via command line, sets the power control attribute to reboot, and transfers to the initialization process; in the initialization process, it stops local system services and transfers the process to the kernel power management system; the kernel management system stores the reason for the silent reboot in a register; then the bootloader reboots and reads the reboot reason as silent; in the native silent boot process, the bootloader does not load the boot flag; then the bootloader updates the environment variables passed to the kernel to carry the silent parameter; based on this environment variable, it updates the kernel boot parameters and implements kernel boot; during kernel boot... When the system reboots, the initialization program parses the kernel boot parameters, converting the silent information in the kernel boot parameters into Android-level system silent boot attributes. Then, a silent boot is performed based on these attributes. This silent boot process includes starting the hardware synthesizer, loading the boot animation, and starting the power management service. Because it's a silent boot, the device screen won't light up when the hardware synthesizer starts; the boot animation loading process is not initiated. After the power management server starts, the display management service starts, and after its execution, the device is notified to go into standby mode. Simultaneously, when the power management service starts, the standby reason is updated to a silent reason, and the process of suspending to memory standby is executed. During this native silent boot process, the device can only respond to the power button to power on after suspending to memory standby. That is, silent boot typically lasts 20 to 30 seconds. Throughout the entire silent boot process, the device screen remains off, and the system cannot respond to any external events, including requests to light up the screen by short-pressing the power button, until the core services are loaded. This prolonged unresponsive black screen state makes it impossible for users to determine whether the device is starting up normally, has crashed, or is experiencing other issues, leading to confusion and anxiety and significantly reducing the user experience.
[0029] To address this technical problem, this application provides the following technical solution: When the current boot phase is the kernel-level boot phase and the current boot phase is a silent boot phase, a first boot event monitoring driver and a silent screen-on driver are mounted; the presence of a boot command is detected based on the first boot event monitoring driver; if the boot command exists, the display of the display device is turned on in response to the boot command, based on the silent screen-on driver. The implementation process can be as follows: Figure 2 As shown, a boot event monitoring driver and a silent screen activation driver are added to the kernel layer boot process. When the silent boot process reaches the kernel layer, the boot command can be detected based on the newly added boot event monitoring driver. After the boot command is detected, the screen is turned on based on the silent screen activation driver, thereby realizing screen activation during the silent boot process and improving the user experience.
[0030] This application provides a power-on processing method, display device, computer device, and storage medium, used to respond to a power-on command during a silent power-on process to achieve silent screen illumination. The electronic device provided in this application can be implemented as various types of user terminals.
[0031] The electronic device runs the power-on processing method provided in the embodiments of this application to respond to the power-on command during the silent power-on process and achieve silent screen lighting.
[0032] The above method can be applied to the boot-up process of many smart TVs, smartphones, or smart screens.
[0033] In one exemplary solution, this boot-up processing method can be applied to the boot-up process of a smart TV. For example, during a cold boot process where the smart TV is powered off and then powered on again, it automatically enters a silent boot mode. When the silent boot process reaches the kernel layer, the kernel layer, upon determining that the current boot mode is silent boot, mounts a first boot event monitoring driver and a silent screen activation driver. When a boot command is detected based on the first boot event monitoring driver, the screen of the smart TV is lit up based on the silent screen activation driver, enabling the smart TV to respond to the boot command during the silent boot process.
[0034] It should be understood that the above is an example of an application scenario for boot processing. There are many other possible application scenarios, which are not limited here.
[0035] The technical solution provided in this application can be applied to various display devices. A display device can also be called a display apparatus, display terminal, or visual presentation device, etc. A display device is an electronic device that converts electrical signals into light signals to present visual information such as images, videos, or text, and typically serves as the core output component of a Human-Machine Interface (HMI).
[0036] For example, display devices can include, but are not limited to, consumer electronics devices, commercial display devices, industrial control equipment, in-vehicle devices, medical devices, or public information display devices. Currently, display devices can specifically take the form of: televisions, computer monitors, laptop computers, tablet computers, smartphones, projectors, wearable devices, in-vehicle display systems, digital signage, all-in-one conference machines, virtual reality (VR) headsets, or augmented reality (AR) glasses, etc.
[0037] For example, in a smart home scenario, display devices can be smart TVs, smart speakers with screens, smart refrigerator door displays, or smart control panels on the wall.
[0038] For example, in commercial and public display scenarios, display devices can be advertising machines in shopping malls, electronic whiteboards in conference rooms, video walls in security monitoring centers, or flight / train information displays in airports and train stations.
[0039] For example, in an in-vehicle environment, the display device can be the vehicle's digital dashboard, central control navigation and entertainment screen, rear seat entertainment display screen, or streaming media rearview mirror, etc.
[0040] For example, in the fields of industrial control and medical care, display devices can be operation terminal monitors on production lines, control panels for CNC machine tools, or medical image displays used to display ultrasound and CT scan results.
[0041] Figure 3 This is a schematic diagram illustrating an exemplary scenario of a display device performing a power-on process according to an embodiment. Figure 3As shown, the user can operate the display device 200 through the controller 100, and the server 300 can provide content interaction for the display device 200 through the network.
[0042] In one exemplary embodiment, the controller 100 can be a remote control. Communication between the remote control and the display device includes infrared protocol communication, Bluetooth protocol communication, and other short-range communication methods, controlling the display device 200 wirelessly or via wired means. Users can control the display device 200 by inputting user commands through buttons on the remote control, voice input, control panel input, etc.
[0043] In another exemplary embodiment, the controller 100 may be other terminal devices (such as mobile phones, tablets, computers, laptops, etc.) that can control the display device 200 through a corresponding application.
[0044] In another exemplary embodiment, the controller 100 may be a physical power button on the display device 200, through which a power-on command is input by short-pressing or long-pressing the physical power button.
[0045] In another exemplary embodiment, the display device 200 can also obtain a power-on command via gestures or other means.
[0046] In another exemplary solution, the display device 200 can also directly receive the user's voice power-on command through a module configured inside the display device 200 for acquiring voice commands, or it can receive the user's voice power-on command through a voice control device set outside the display device 200.
[0047] In another exemplary embodiment, the display device 200 also communicates with the server 300. The display device 200 may be allowed to communicate via a local area network (LAN), wireless local area network (WLAN), and other networks. The server 300 may provide various content and interactive features to the display device 200. The server 300 may be a cluster or multiple clusters, and may include one or more types of servers.
[0048] like Figure 4 As shown, the display device 200 may include at least one of the following: a tuner 210, a communicator 220, a detector 230, an external device interface 240, a processor 250, a display 260, an audio output interface 270, a memory, a power supply, and a user interface.
[0049] In some embodiments, processor 250 may include a processor, a video processor, an audio processor, a graphics processor, RAM, ROM, and a first to an nth interface for input / output.
[0050] The display 260 may include the following components: a display screen component for presenting images; a driving component for driving image display; a component for receiving image signals output from the processor 250 and displaying video content, image content, and a menu control interface; and a component for a user control UI interface.
[0051] The display 260 can be an LCD display, an OLED display, or a projection display, and can also be a projection device and a projection screen.
[0052] The communicator 220 is a component used to communicate with external devices or servers according to various communication protocol types. For example, the communicator may include at least one of the following: a WIFI module, a Bluetooth module, a wired Ethernet module, other network communication protocol chips or near-field communication protocol chips, and an infrared receiver. The display device 200 can establish the transmission and reception of control signals and data signals with the controller 100 or the server 300 through the communicator 220.
[0053] The user interface can be used to receive control signals from the controller 100 (such as an infrared remote control).
[0054] Detector 230 is used to collect signals from the external environment or to interact with the external environment. For example, detector 230 includes a light receiver, a sensor for collecting ambient light intensity; or, detector 230 includes an image acquisition device, such as a camera, which can be used to collect external environmental scenes, user attributes, or user interaction gestures; or, detector 230 includes a sound acquisition device, such as a microphone, for receiving external sounds.
[0055] The external device interface 240 may include, but is not limited to, one or more of the following: High Definition Multimedia Interface (HDMI), analog or high-definition component input interface (component), composite video input interface (CVBS), USB input interface (USB), RGB port, etc. It may also be a composite input / output interface formed by multiple interfaces mentioned above.
[0056] The tuner / demodulator 210 receives broadcast television signals via wired or wireless means, and demodulates audio and video signals, such as EPG data signals, from multiple wireless or wired broadcast television signals. In some embodiments, the processor 250 and the tuner / demodulator 210 may be located in different separate devices, that is, the tuner / demodulator 210 may also be located in an external device of the main device where the processor 250 is located, such as an external set-top box.
[0057] Processor 250 controls the operation of the display device and responds to user operations through various software control programs stored in memory. Processor 250 controls the overall operation of display device 200. For example, in response to receiving a user command to select a UI object to display on display 260, processor 250 can execute operations related to the object selected by the user command.
[0058] In some embodiments, processor 250 includes a central processing unit (CPU), a video processor, an audio processor, a graphics processing unit (GPU), RAM (Random Access Memory), and ROM (Read-Only Memory). Only Memory (ROM), at least one of the following: first to nth interface for input / output, communication bus (Bus), etc.
[0059] Based on the aforementioned display device 200, users can control the display device 200 to start and operate through specific power-on interactive actions. Depending on the user's input power-on interactive action, the display device 200 supports two power-on methods: AC / DC startup and standby startup. AC / DC startup refers to the startup method where the display device 200 is connected to an AC or DC power supply, enabling the various modules within the display device 200 to operate. Standby startup refers to the startup method where the display device 200 is woken from standby mode and enters the operating state.
[0060] Corresponding to the power-on startup method, the display device 200 also supports different shutdown methods, namely AC / DC shutdown and standby shutdown. Similarly, AC / DC shutdown is achieved by disconnecting the display device 200 from the power supply, while standby shutdown can be achieved by using the standby button on the display device 200 to turn off the display device 200 without disconnecting the power supply.
[0061] In some embodiments, after the display device 200 is powered on, it generates a power-on signal. This signal activates the standby program within the display device 200, allowing it to enter a standby state from a completely off state. That is, after the display device 200 is powered on, a portion of the control program automatically starts running to enter the standby state. Once in standby mode, the display device 200 can receive some control commands, such as remote control commands sent by the user through the controller 100. Some of the control commands received by the display device 200 can be used to transition the display device 200 from standby mode to normal operation; these commands can be called power-on commands. For example, the controller 100 may have a power button, allowing the user to press the power button to control the display device 200 to enter normal operation from standby mode, i.e., to input a power-on command.
[0062] Based on the above description, the power-on process of the display device 200 can include the following two stages: after the user connects the power supply to the display device 200, the display device 200 enters the standby state; and when the user inputs a power-on command based on the standby state of the display device 200, the display device 200 enters the normal operation state from the standby state.
[0063] The power-on process from connecting the display device 200 to the display device 200 entering standby mode can be set to silent power-on. Currently, the duration of silent power-on is typically 20 to 30 seconds. Therefore, during the entire silent power-on process, the device screen remains off, and the system cannot respond to any external events, including requests to light up the screen by short-pressing the power button, until the core services are loaded. This prolonged unresponsive black screen state makes it impossible for users to determine whether the device is starting normally, has crashed, or is experiencing other issues, leading to confusion and anxiety, and significantly reducing the user experience. Therefore, this application provides... Figure 5 The power-on process is shown below.
[0064] like Figure 5 The diagram shown is a flowchart of one embodiment of the power-on processing method in this application, which may include the following steps 501-503, as detailed below: 501. When the current boot startup stage is the kernel layer boot stage and the current boot startup stage is the silent boot stage, mount the first boot event monitoring driver and the silent screen tapping driver.
[0065] In this embodiment, during a cold boot process involving power-on or restart, the display device enters a silent boot process. When the silent boot process reaches the kernel-level startup stage, it first determines the current boot mode. In this embodiment, the display device's system can achieve this by reading the boot arguments / cmdline passed to the kernel by the general boot loader. When the display device's system recognizes a specific flag indicating that it is currently in the "silent boot stage," it will execute the operation of mounting the first boot event monitoring driver and the silent screen tapping driver.
[0066] It should be understood that mounting is used to instruct the loading of driver code into the kernel memory space and the execution of its initialization functions, thereby registering it with the appropriate kernel subsystem and bringing it into an active state, ready to receive and process events.
[0067] The kernel-level startup phase refers to the period when the operating system kernel (such as the Linux Kernel) of the display device has taken over control and startup parameters from the Bootloader startup phase, and is performing its own initialization, hardware detection, and loading of core drivers.
[0068] The silent startup phase refers to the kernel layer knowing, through specific parameters or configurations, that this startup will adopt a mode where the screen remains off and there is no sound, and the system loads in the background.
[0069] Optionally, the kernel layer can confirm that the current boot mode is a silent boot mode by indicating parameters. That is, the kernel layer can receive the first parameter passed by the generic boot loader (boot), where the first parameter is used to indicate that the current boot mode is a silent boot mode.
[0070] Optionally, the generic bootloader layer can also generate a second parameter, which indicates that the current boot phase is a silent boot phase. This second parameter is passed by the generic bootloader layer to the power management service layer (Power server).
[0071] Optionally, during the silent boot process, this universal boot loading layer can also load boot identifier data and store it in the image cache. This allows for earlier screen illumination during the subsequent silent boot process, ensuring visual quality, eliminating visual gaps or screen flickering, and ultimately achieving a user experience with extremely fast perceived speed.
[0072] Optionally, based on the various possible implementations of the boot command, the first boot event monitoring driver can have multiple implementations.
[0073] In one exemplary scheme, the power-on command is an infrared command. For example, the power-on command is an infrared command issued by a remote control and sent to the display device (such as a smart TV, set-top box, etc.) via infrared protocol communication. In this case, the first power-on event monitoring driver can be specifically implemented as an infrared event monitoring driver. In this embodiment, the infrared event monitoring driver works by communicating with the device's infrared receiver module. After loading, the driver puts the infrared receiver module into an active listening state. When the remote control emits an infrared signal, the infrared receiver module receives and initially demodulates the signal, and notifies the central processing unit via interrupt or direct memory access. The interrupt handler function of the infrared event monitoring driver is awakened and is responsible for reading the decoded data (usually user code and key code) from the hardware buffer and comparing it with the preset "power-on" command code (e.g., the key code corresponding to the power button on the remote control). Once a match is successful, the driver determines that a valid power-on command has been received.
[0074] In one exemplary scheme, the power-on command is a physical button command. For example, the power-on command can be a specific operation by the user on a physical button of the display device (such as the power button, volume buttons, home button, etc.). In this case, the first power-on event monitoring driver can be specifically implemented as a button event monitoring driver. In this embodiment, the button event monitoring driver interacts directly with the device's general-purpose input / output controller or dedicated button controller hardware. During initialization, the driver requests and registers an interrupt service routine for the general-purpose input / output pin connected to the target physical button. When the user operates the button, causing a change in the level of the general-purpose input / output pin, the hardware generates an interrupt, directly triggering the interrupt service routine of the driver. This routine can then analyze the type of button event, such as calculating the duration of the button press using a kernel timer to distinguish between "short press" and "long press"; or recording the number of button presses to identify "double press", etc. When the detected button event sequence matches a preset power-on command pattern (e.g., "short press of the power button once"), the driver confirms that the power-on command has been received and triggers subsequent screen tap operations.
[0075] In one exemplary embodiment, the power-on command is a touch gesture command. For example, on a device equipped with a touchscreen, the power-on command could be a specific touch gesture performed by the user while the screen is off (such as "double-tap to wake," "swipe up," etc.). In this case, the first power-on event monitoring driver can be specifically implemented as a touch event monitoring driver. In this embodiment, the touch event monitoring driver collaborates with the touch panel controller IC. Many modern touchscreen controllers support a low-power "gesture wake-up" mode. When the system enters silent boot, the driver sends a command to the touchscreen controller via a bus such as I2C or SPI to enable it to enter this low-power gesture monitoring mode and configure the specific gestures to be recognized. In this mode, the touchscreen controller scans the screen with extremely low power consumption. When it detects a gesture that matches a preset value, it sends an interrupt signal to the main processor via a dedicated interrupt line. The touch event monitoring driver registers to listen for this interrupt, and when the interrupt occurs, it confirms that the power-on command has been received.
[0076] 502. Based on the first boot event monitoring driver, detect whether a boot command exists.
[0077] In this embodiment, the first power-on event monitoring driver can be configured to interact directly with a general-purpose input / output controller or a button controller. During initialization, the first power-on event monitoring driver requests to listen for interrupts on general-purpose input / output pins connected to the power button, volume buttons, or other designated buttons. After mounting is complete, the first power-on event monitoring driver begins to continuously monitor for the presence of a predefined power-on command.
[0078] It should be understood that the monitoring process of the first boot event monitoring driver occurs at the kernel level. As an independent monitoring unit, it can be configured to continuously check the hardware input sources bound to it. Once an event that meets the preset conditions is detected, it is determined that a "boot command" has been received.
[0079] In this embodiment, the power-on command is used to instruct one or a group of physical operations generated by the user and defined by the system as "intending to turn on the screen and start using the device".
[0080] Optionally, the process of the first boot event monitoring driver detecting the boot command can be implemented in several ways: In one exemplary scenario, interrupt-based detection is employed. During initialization, the first power-on event monitoring driver can register a handler function for a target hardware interrupt (such as a level change interrupt on a power button's general-purpose input / output pin) with the kernel. When the user presses the power button, the hardware generates an interrupt signal, the processor suspends its current task, and immediately jumps to execute the driver's handler function.
[0081] During the execution of the handler function or its scheduler, the first boot event monitoring driver analyzes the type of interrupt, such as whether it is a key press or release, and may start a kernel timer to calculate the duration of the key press.
[0082] The first boot event monitoring driver will match detected events (such as "short press", "long press", "double press") with preset "boot command" patterns. For example, the system may define "any short press of the power button" as the boot command. If the match is successful, the driver confirms that the "boot command" exists.
[0083] Based on the above description, taking the first boot event monitoring driver as an example of an infrared event monitoring driver, the detection process of this boot command will be explained below. The implementation process can be as follows: When the display device is powered back on from a power-off state, the boot ROM code of the System-on-Chip (SoC) begins execution and loads a generic bootloader layer stored in non-volatile memory (such as eMMC or NAND Flash) into the system RAM. This generic bootloader layer is configured to perform a silent boot according to a preset boot configuration.
[0084] In this silent boot mode, after completing necessary hardware initialization (such as DDR memory controller initialization), the generic bootloader layer adds a target flag (e.g., boot_mode=silent or androidboot.silentboot=1) to the kernel command line before passing control to the operating system kernel layer to obtain the first and second parameters. These first and second parameters are the basis for the kernel layer to determine whether the current boot mode is silent boot.
[0085] The generic bootloader loads the operating system kernel image into memory and jumps to the kernel boot phase, at which point the kernel begins its own initialization process. This infrared event monitoring driver can be configured as a built-in kernel driver or as a very early loaded kernel module to ensure its availability in the initial stages of system kernel startup. When the kernel begins scanning and matching devices and drivers, the bus corresponding to the physical infrared receiver module (IR Receiver) will detect this infrared event monitoring driver.
[0086] The kernel layer calls the detection function of the first infrared event monitoring driver. Inside this function, the infrared event monitoring driver first parses the first parameter and checks whether the aforementioned target flag exists.
[0087] If a silent start flag is detected, the infrared event monitoring driver will execute its "silent monitoring" logic. This involves initializing the infrared receiving hardware and configuring it to enter a low-power, interrupt-driven listening mode. For example, the infrared event monitoring driver will register one or more predefined infrared key codes associated with the "power-on" function with the infrared receiving hardware. Then, the first infrared event monitoring driver will register an interrupt service routine with the kernel-level interrupt subsystem to interrupt the signal from the infrared receiving module. In this mode, the infrared event monitoring driver monitors the power-on command. When the user presses the power button on the remote control, the infrared receiving module receives and decodes the infrared signal. The hardware decoding logic determines whether the key code matches the driver's preset "power-on key code," thus confirming that a power-on command has been received.
[0088] 503. When the power-on command is present, in response to the power-on command, the display of the display device is turned on based on the silent screen driver.
[0089] In this embodiment, the silent screen-on driver can be configured as a minimal display control driver, whose core function is to perform the most basic screen-on operation. This silent screen-on driver can be configured to communicate with the display controller or the host controller of the mobile processor interface display bus interface. During the initialization process in the kernel layer startup phase, the silent screen-on driver can preset a series of low-level command sequences for lighting up the screen. These commands may include: powering the display panel, turning on the backlight controller, and sending commands to the target mobile processor interface display bus interface to light up the panel from a black screen state, etc.
[0090] Upon detecting a power-on command, the display device's system will invoke or trigger the silent screen-on driver. After receiving the power-on request, the silent screen-on driver sends a series of preset low-level control commands to the display hardware (such as the display controller, backlight controller, and display panel), thereby driving the display device's monitor from an off state to an on state. The execution flow during this process can be as follows: After detecting the boot command, the silent screen-on driver can be triggered through function calls or kernel notification mechanisms.
[0091] Once triggered, this silent screen-clicking driver can perform one or more of the following operations in sequence: Power Management: By interacting with the power management integrated circuit, it provides the required operating voltage to the display panel.
[0092] Clock and Reset: Enables the necessary clock signals for interface modules such as the display controller, mobile industry processor interface, and display bus interface, and performs hardware reset operations.
[0093] Display controller initialization: Send an initialization command sequence to the display controller to configure its working mode, timing parameters, etc.
[0094] Panel wake-up: Sends a command to the display panel driver to exit deep sleep via the mobile industrial processor interface display bus interface.
[0095] Backlight on: Controls the backlight driver to gradually increase the brightness of the LED backlight to a preset value, causing the screen to emit light.
[0096] It should be understood that while the silent screen-on driver completes the power-on operation, the upper-layer services (Framework layer) of the display device's operating system continue to load. Once the system's UI (such as the lock screen) is ready for rendering, the standard display driver stack takes over display control. At this point, the screen is lit, and the user interface can be directly drawn on the screen, thus achieving extremely low latency from when the user presses a button to when they see the usable interface, completing the closed loop of silent startup and rapid response.
[0097] Optionally, after the screen-on operation is implemented during the kernel layer startup phase, the kernel layer can modify the first parameter to obtain a third parameter. This third parameter indicates that the current boot phase has exited the silent boot phase. This allows the subsequent power management service layer to modify its boot mode based on the modified parameter, thereby ensuring the continuity of the boot process.
[0098] It should be understood that the first parameter and the third parameter can be different values of the same parameter name.
[0099] Optionally, after the screen-on operation is implemented during the kernel layer startup phase, the kernel layer can unload the silent screen-on driver, thereby reducing the number of programs running during the startup process and thus speeding up the startup.
[0100] In this embodiment, after the kernel layer startup phase is completed, the operating system of the display device jumps to execute the power management service layer startup phase.
[0101] Optionally, during the startup phase of the power management service layer, the power management service layer may obtain the first parameter and the second parameter, or the power management service layer may obtain the first parameter and the third parameter to determine whether its current power-on startup phase is a silent startup phase.
[0102] Optionally, when the power management service layer receives the first parameter and the second parameter, it can confirm that the current boot-up phase is still a silent boot phase, that is, when the kernel layer boot phase has not exited the silent boot phase, the power management service layer can start the second boot event monitoring driver; and detect whether the boot command exists based on the second boot event monitoring driver; if the boot command exists, respond to the boot command and turn on the display of the display device based on the silent screen-on driver.
[0103] It should be understood that during the startup phase of the power management service layer, the second power-on event monitoring driver can be either the display device's native power-on event monitoring driver or the same driver as the first power-on event monitoring driver; no specific limitation is made here. During this startup phase, the implementation process of the silent screen-clicking driver is the same as described above, and will not be repeated here.
[0104] Optionally, after implementing the operation of prematurely turning on the screen during the silent startup process in the startup phase of the power management service layer, the power management service layer can also uninstall the silent screen-on driver and execute the standby process. In this way, after confirming that the silent screen-on operation has been performed, uninstalling the silent screen-on driver can reduce the number of programs running during the startup process, thereby speeding up the startup.
[0105] Optionally, when the silent startup phase ends and no power-on command is detected (i.e., no power-on command is received throughout the entire silent startup process), the power management service layer unloads the silent screen-on driver and executes the standby process. Unloading the silent screen-on driver when it is confirmed that silent screen-on operation is unnecessary reduces the number of programs running during startup, thereby speeding up the startup process.
[0106] Optionally, upon receiving the second and third parameters, the power management service layer can confirm that the current boot process has exited the silent boot phase, meaning the kernel layer boot phase has exited the silent boot phase. In this way, after the screen has lit up during the silent boot process, the power management service layer switches its boot mode, ensuring visual continuity during boot and improving the user experience.
[0107] Optionally, if the current boot phase is the power management service layer boot phase and the current boot phase has exited the silent boot phase, the silent screen-clicking driver can be uninstalled. Uninstalling the silent screen-clicking driver after confirming that a silent screen-clicking operation has been performed can reduce the number of programs running during the boot process, thereby speeding up the boot process.
[0108] It should be understood that if the operation of uninstalling the silent screen driver is completed during the kernel-level startup phase, then this operation may not be performed if the current startup phase is the power management service layer startup phase and the current startup phase has exited the silent startup phase.
[0109] Based on the above, the following will be based on... Figure 6 The flowchart shown illustrates the power-on processing method in this application: like Figure 6 As shown, after power-on, the general bootloader layer starts up and parses the current configuration. If the current configuration indicates that the display device does not support silent boot, the normal boot process is executed directly. If the current configuration indicates that the display device supports silent boot, the general bootloader layer sets the silent boot flag to the boot parameters of the general bootloader layer, that is, the general bootloader sets the first parameter and the second parameter. At the same time, the general bootloader layer loads the boot flag data and stores the boot flag data in the image buffer area so that the boot flag data can be directly called for display when the screen is turned on silently later. After initialization is completed, the general bootloader layer transfers the control and parameters of the silent boot process to the kernel layer. During the kernel layer startup phase, the kernel layer determines whether the current boot startup phase is silent boot based on the first parameter. If yes, the remote control driver and silent screen-on driver are mounted. If not, the normal boot process is executed, and after the kernel layer startup is completed, the power management service layer startup is executed. After the remote control driver and silent screen-on driver are mounted... After activation, the remote control driver continuously checks for a power-on command (e.g., whether a power button is pressed). If a command is present, the backlight is activated, and the normal power-on process is executed (the system jumps to the power management service layer and performs normal power-on). If no command is present, the system continues checking until the kernel layer completes its startup, then jumps to the power management service layer. During the power management service layer startup phase, the display device determines whether the initial power-on mode is a silent power-on mode based on the second parameter. If not, the normal power-on process is executed. If so, the system determines whether the kernel layer has exited the silent power-on mode based on the first or third parameter. If not, the normal power-on process is executed. If so, the system executes the silent power-on mode and starts its built-in power-on event monitoring driver. Based on the built-in power-on event monitoring driver, the system continuously checks for a power-on command (e.g., whether a power button is pressed). If a command is present, the normal power-on process is executed. If no command is present, the system continues checking for a power-on command. If no power-on command is present after the silent power-on startup phase is complete, the system suspends to memory standby. Understandably, the display device can uninstall the silent touch screen driver before it is suspended to memory.
[0110] To better implement the power-on processing method in the embodiments of this application, based on the power-on processing method, the embodiments of this application also provide a display device, such as... Figure 7As shown, the display device 700 includes: Processor 701 and display 702; The processor 701 is configured to, when the current boot-up phase is the kernel-level boot-up phase and the current boot-up phase is the silent boot-up phase, mount a first boot-up event monitoring driver and a silent screen-on driver; detect whether a boot command exists based on the first boot-up event monitoring driver; and, when the boot command exists, respond to the boot command by turning on the display 702 of the display device based on the silent screen-on driver.
[0111] In this embodiment, a boot event monitoring driver and a silent screen activation driver are added to the kernel layer boot process. This allows the boot command to be detected based on the newly added boot event monitoring driver when the silent boot process reaches the kernel layer. After the boot command is detected, the screen is turned on based on the silent screen activation driver, thereby enabling the screen to be turned on during the silent boot process and improving the user experience.
[0112] In some embodiments of this application, the processor 701 is specifically used for: Obtain the first parameter, which indicates that the current boot-up phase is a silent boot phase; Based on this first parameter, the current boot-up phase is determined to be a silent boot phase.
[0113] In this embodiment, configuration parameters are used to enable the kernel layer to promptly confirm that the current startup mode is silent startup during the startup phase, thereby achieving precise control over the silent startup mode.
[0114] In some embodiments of this application, the processor 701 is specifically used for: The first parameter is generated when the current boot stage is the general boot loading layer boot stage and the current boot stage is the silent boot stage; The first parameter is passed to the kernel layer.
[0115] In this embodiment of the application, the configuration parameter is set in the initial process of the boot process (i.e., the general boot loading layer) and the configuration parameter is passed to the kernel layer, so that the kernel layer can promptly confirm that the current boot mode is silent boot, thereby achieving precise control over the silent boot mode.
[0116] In some embodiments of this application, the processor 701 is specifically used for: When the current boot startup phase is the general boot loading layer startup phase and the current boot startup phase is the silent startup phase, a second parameter is generated, which is used to indicate that the current boot startup phase is the silent startup phase; The second parameter is passed to the power management service layer.
[0117] In this embodiment, the configuration parameter is set in the initial process of the boot process (i.e., the general boot loading layer) and the configuration parameter is passed to the power management service layer, so that the power management service layer can promptly confirm that the current boot mode is silent boot during the startup phase, thereby achieving precise control over the silent boot mode.
[0118] In some embodiments of this application, the processor 701 is specifically used for: When the current boot startup phase is the general boot loading layer startup phase and the current boot startup phase is the silent startup phase, the boot identifier data is loaded and the boot identifier data is stored in the image cache area.
[0119] In this embodiment, the boot identifier data is preloaded, which can be conveniently displayed when the screen is turned on early in the future, thereby eliminating the problems of visual fragmentation or screen flicker, and thus achieving a user experience with extremely fast perception speed.
[0120] In some embodiments of this application, the processor 701 is specifically used to: modify the first parameter to the third parameter, and pass the third parameter to the power management service layer, wherein the third parameter is used to indicate that the current power-on startup phase has exited the silent startup phase; Uninstall the silent screen driver.
[0121] In this embodiment, by modifying parameters, the subsequent power management service layer can adjust its startup mode according to the modified parameters, thereby ensuring the continuity of the startup process. Unloading the silent screen-touch driver can reduce the number of programs running during startup, thus speeding up the startup process.
[0122] In some embodiments of this application, the processor 701 is specifically used to: start the second boot event monitoring driver when the current boot startup phase is the power management service layer startup phase and the current boot startup phase is the silent startup phase; The second boot event monitoring driver detects whether the boot command exists. When the power-on command is present, in response to the power-on command, the display of the display device is turned on based on the silent screen driver.
[0123] In this embodiment, when the power management server is not lit up and is still in the silent startup phase, its corresponding boot event monitoring driver is started and the silent screen driver mounted in the kernel layer is reused to enable the screen to be lit up in advance during the silent startup process, thereby improving the user experience.
[0124] In some embodiments of this application, the processor 701 is specifically used for: When the silent startup phase ends and no power-on command is detected, the silent screen driver is uninstalled and the standby process is executed.
[0125] In this embodiment of the application, when it is confirmed that a silent screen tapping operation is not required, uninstalling the silent screen tapping driver can reduce the number of running programs during the startup process, thereby speeding up the startup speed.
[0126] In some embodiments of this application, the processor 701 is specifically configured to: after turning on the display of the display device based on the silent screen driver in response to the power-on command, unload the silent screen driver.
[0127] In this embodiment of the application, after confirming that the silent screen tapping operation has been performed, uninstalling the silent screen tapping driver can reduce the number of running programs during the startup process, thereby speeding up the startup speed.
[0128] In some embodiments of this application, the processor 701 is specifically used for: Obtain the first parameter and the second parameter, wherein the second parameter is passed from the general boot loader layer to the power management service layer, the first parameter is passed from the kernel layer to the power management server, the second parameter is used to indicate that the current boot stage is a silent boot stage, and the first parameter is used to indicate that the current boot stage is a silent boot stage; Based on the first parameter and the second parameter, the current boot-up phase is determined to be a silent boot phase.
[0129] In this embodiment, the power management service layer determines the silent startup mode through two parameters, which can more accurately and timely confirm that the current startup mode is silent startup, thereby achieving precise control over the silent startup mode.
[0130] In some embodiments of this application, the processor 701 is specifically used to: execute a normal boot process when the current boot phase is the power management service layer boot phase and the current boot phase has exited the silent boot phase.
[0131] In this embodiment, after the screen has been lit during the silent startup process, the startup mode of the power management service layer is switched to ensure visual continuity during startup and improve user experience.
[0132] In some embodiments of this application, the processor 701 is specifically used for: Obtain the second parameter and the third parameter, wherein the second parameter is passed from the general boot loading layer to the power management service layer, and the third parameter is passed from the kernel layer to the power management server. The second parameter is used to indicate that the current boot stage is a silent boot stage, and the third parameter is used to indicate that the current boot stage has exited the silent boot stage. Based on the second and third parameters, it is determined that the current boot-up phase has exited the silent boot phase.
[0133] In this embodiment, the power management service layer uses two parameters to determine whether the silent boot mode has been exited, which can more accurately and timely confirm the current boot mode, thereby achieving precise control over the power-on process.
[0134] In some embodiments of this application, the processor 701 is specifically used to: unload the silent screen driver when the current boot-up phase is the power management service layer boot-up phase and the current boot-up phase has exited the silent boot-up phase.
[0135] In this embodiment of the application, after confirming that the silent screen tapping operation has been performed, uninstalling the silent screen tapping driver can reduce the number of running programs during the startup process, thereby speeding up the startup speed.
[0136] This application also provides a computer device that integrates any of the display devices provided in this application, the computer device comprising: One or more processors; memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor from the steps of the boot process method in any of the embodiments described above.
[0137] This application provides a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps of any of the boot processing methods provided in this application.
[0138] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.
[0139] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.
[0140] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.
[0141] The above provides a detailed description of a power-on processing method, display device, computer device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A power-on processing method, applied to a display device, the display device including a monitor, characterized in that, include: When the current boot-up phase is the kernel layer boot-up phase and the current boot-up phase is the silent boot-up phase, the first boot event monitoring driver and the silent screen tapping driver are mounted. Based on the first boot event monitoring driver, detect whether a boot command exists; When the power-on command is present, in response to the power-on command, the display of the display device is turned on based on the silent screen-on driver.
2. The method according to claim 1, characterized in that, Before detecting the presence of a boot command based on the first boot event monitoring driver, the method further includes: Obtain the first parameter, which is used to indicate that the current boot-up phase is a silent boot phase; Based on the first parameter, the current boot-up phase is determined to be a silent boot phase.
3. The method according to claim 2, characterized in that, The method further includes: The first parameter is generated when the current boot startup phase is the general boot loading layer startup phase and the current boot startup phase is the silent startup phase; The first parameter is passed to the kernel layer.
4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: When the current boot startup phase is the general boot loading layer startup phase and the current boot startup phase is the silent startup phase, a second parameter is generated, the second parameter being used to indicate that the current boot startup phase is the silent startup phase; The second parameter is passed to the power management service layer.
5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: When the current boot startup phase is the general boot loading layer startup phase and the current boot startup phase is the silent startup phase, the boot identifier data is loaded and the boot identifier data is stored in the image cache area.
6. The method according to any one of claims 1 to 3, characterized in that, After responding to the power-on command and turning on the display of the display device based on the silent screen-on driver, the method further includes: Modify the first parameter to the third parameter, and pass the third parameter to the power management service layer. The third parameter is used to indicate that the current boot-up phase has exited the silent boot phase. The first parameter is passed by the general boot loading layer and is used to indicate that the current boot-up phase is the silent boot phase. Uninstall the silent screen driver.
7. The method according to any one of claims 1 to 3, characterized in that, After detecting the presence of a boot command based on the first boot event monitoring driver, the method further includes: When the current boot-up phase is the power management service layer boot-up phase and the current boot-up phase is the silent boot-up phase, the second boot-up event monitoring driver is started. The second power-on event monitoring driver is used to detect whether the power-on command exists. When the power-on command is present, in response to the power-on command, the display of the display device is turned on based on the silent screen-on driver.
8. The method according to claim 7, characterized in that, After detecting the presence of the boot command based on the second boot event monitoring driver, the method further includes: When the silent startup phase ends and no power-on command is detected, the silent screen-on driver is uninstalled and a standby process is executed.
9. The method according to claim 7, characterized in that, After responding to the power-on command and turning on the display of the display device based on the silent screen-on driver, the method further includes: Uninstall the silent screen driver.
10. The method according to claim 7, characterized in that, Before starting the second boot event monitoring driver, the method further includes: Obtain the first parameter and the second parameter, wherein the second parameter is passed from the general boot loader layer to the power management service layer, the first parameter is passed from the kernel layer to the power management service layer, the second parameter is used to indicate that the current boot stage is a silent boot stage, and the first parameter is used to indicate that the current boot stage is a silent boot stage; Based on the first parameter and the second parameter, the current boot-up phase is determined to be a silent boot phase.
11. The method according to any one of claims 1 to 3, characterized in that, After detecting the presence of a boot command based on the first boot event monitoring driver, the method further includes: When the current boot-up phase is the power management service layer boot-up phase and the current boot-up phase has exited the silent boot phase, the normal boot-up process is executed.
12. The method according to claim 11, characterized in that, Before executing the normal boot process, the method further includes: Obtain the second parameter and the third parameter, wherein the second parameter is passed from the general boot loader layer to the power management service layer, and the third parameter is passed from the kernel layer to the power management service layer. The second parameter is used to indicate that the current boot stage is a silent boot stage, and the third parameter is used to indicate that the current boot stage has exited the silent boot stage. Based on the second parameter and the third parameter, it is determined that the current boot-up phase has exited the silent boot phase.
13. The method according to claim 10, characterized in that, The method further includes: When the current boot-up phase is the power management service layer boot-up phase and the current boot-up phase has exited the silent boot-up phase, the silent screen-clicking driver is uninstalled.
14. A display device, characterized in that, include: Processor and display; The processor is configured to, when the current boot-up phase is the kernel-level boot-up phase and the current boot-up phase is the silent boot-up phase, mount a first boot event monitoring driver and a silent screen-on driver; detect whether a boot command exists based on the first boot event monitoring driver; and, when the boot command exists, respond to the boot command by turning on the display of the display device based on the silent screen-on driver.
15. A computer device, characterized in that, The computer device includes: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the method of any one of claims 1 to 13.
16. A computer-readable storage medium, characterized in that, It contains a computer program that is loaded by a processor to perform the steps of the method according to any one of claims 1 to 13.