The parameter management module, namely, sysparam, provides an easy-to-use key-value pair access interface for system services to configure service functions based on their own system parameters.
The parameter management subsystem, namely, sysparam, provides easy-to-use key-value pair access interfaces for system services to customize functions based on their own system parameters.
### Basic Concepts
Figure 1 System parameter operation primitives
#### Operation Primitives
Figure 1 shows the primitives used to operate system parameters. For details about how they work, see Figure 1.
Figure 1 Overview of system parameter operation primitives
**Table 1** Description of system parameter operation primitives
| Operation Primitive| Description|
| Operation Primitive | Description |
| -------- | -------- |
| get | Obtains the value of a system parameter. |
| set | Sets the value of a system parameter. |
| wait | Waits for value change of a system parameter synchronously.|
| watch | Observes value change of a system parameter asynchronously.|
#### System Parameter Definition
#### Parameter Definition
- Naming format
A system parameter name consists of multiple segments in dotted notation. Each segment can be a string that consists of letters, digits, and underscores (_). The total length cannot exceed 96 bytes. System parameter names are categorized into the following two types.
A system parameter name consists of multiple segments in dotted notation. Each segment can be a string that consists of letters, digits, and underscores (_). The total length cannot exceed 96 bytes.
Two naming formats are supported for system parameters, as described in Table 2.
**Table 2** System parameter names
...
...
@@ -33,31 +42,31 @@ Figure 1 System parameter operation primitives
- Type
System parameters are categorized into three types.
System parameters are categorized into three types, as described in Table 3.
**Table 3** System parameter types
| Type| Prefix| Description|
| -------- | -------- | -------- |
| Constant| const. | Constant parameter, which will not be changed once a value is assigned. The value can contain a maximum of 4,096 bytes (including the terminator).|
| Writable| Others| Writable parameter, which will be lost after system restart. The value can contain a maximum of 96 bytes (including the terminator).|
| Persistent| persist. | Writable and persistent parameter, which will not be lost after system restart. The value can contain a maximum of 96 bytes (including the terminator).|
| Constant| const. | Constant parameter, which will not be changed once a value is assigned. The value can contain a maximum of 4,096 bytes (including the end-of-text character).|
| Writable| Others| Writable parameter, which will be lost after system restart. The value can contain a maximum of 96 bytes (including the end-of-text character).|
| Persistent| persist. | Writable and persistent parameter, which will not be lost after system restart. The value can contain a maximum of 96 bytes (including the end-of-text character).|
The general naming format is as follows:
Given below is the general naming format for system parameters:
```
[ const | persist ].$sub_system.$desc
```
**$sub_system** is the name of the subsystem or module.
**$sub_system** is the subsystem or module name.
**$desc** indicates the description of a system parameter. The description can contain multiple segments in dotted notation.
**$desc** is the parameter description, which can contain multiple segments in dotted notation.
#### Definition Rules
#### Parameter Definition Rule
Each subsystem defines the system parameters of its own modules, including the system parameter name, default value, and access permission information.
System parameters are defined per module on each subsystem. The parameter definition includes the system parameter name, default value, and access permission information.
-System parameter value definition file
-Value definition file
-The system parameter value definition file ends with the **.para** extension. An example of the file format is as follows:
-A value definition file of system parameters ends with the **.para** extension. The following is an example format of file content:
```shell
# This is comment
...
...
@@ -66,43 +75,49 @@ Each subsystem defines the system parameters of its own modules, including the s
const.telephony.enable=false|true
const.test.withblank=My Value
const.test.withcomment=MyValue # This should be ommitted
const.test.withcomment=MyValue # This should be omitted
const.test.multiline="This is a multiline parameter.
Line2 value.
Last line."
```
-You must use a complete system parameter command when assigning a value for a system parameter. The following table describes the value assignment modes.
-A complete system parameter command is required to assign a value for a system parameter. See Table 4 for the value assignment modes.
**Table 4** Value assignment modes
**Table 4** Description of value assignment modes
| Type| Example| Description|
| -------- | -------- | -------- |
| String | const.product.name=OHOS-PRODUCT | A multi-line string must be enclosed in double quotation marks ("").|
| Number | const.os.version.api=26 | Numbers do not need to be enclosed in quotation marks.|
| String | const.product.name=OHOS-PRODUCT | A string that spans multiple lines must be enclosed in double quotation marks ("").|
| Number | const.os.version.api=26 | A number that spans multiple lines does not need to be enclosed in double quotation marks ("").|
| Boolean | const.telephony.enable=false | A Boolean value can be **0**, **1**, **false**, or **true**.|
- DAC definition file
Currently, access permissions of system parameters are managed in Discretionary Access Control (DAC) mode. The access permission definition file ends with the **.para.dac** extension. The following is an example:
Access permissions of system parameters are managed in discretionary access control (DAC) mode. A DAC definition file ends with the **.para.dac** extension. The following is an example format of DAC information:
```java
const.product.="root:root:660"
```
As shown above, we can use **parameter directory** to define the same access permission for system parameters with the same prefix. The DAC information is divided into three segments, user, group, and UGO rule, which are separated using a semicolon (:).
As shown in this example, a **parameter directory** can be used to define the same access permission for system parameters with the same prefix. A piece of DAC information is divided into three segments, user, group, and UGO rule, which are separated using a semicolon (:).
> **NOTE**
>
> Ugo is the abbreviation for user access, group access, ad other system user's access, respectively. These permissions are set to allow or deny access to members of their own group, or any other groups.
The following figure shows the structure of the UGO rule.
Figure 2 shows the UGO rule structure.
**Figure 2** UGO rule structure
**Figure 2**Overview of the UGO rule structure
- SELinux policy for system parameter configuration
- SELinux policy
- Add SELinux tags.
An SELinux policy defines the access permissions for all users, programs, processes, and files.
To add a SELinux tag to system parameters, you first need to define the tag in the **/base/security/selinux/sepolicy/base/public/parameter.te** file. For example:
- Adding an SELinux tag
To add an SELinux tag to system parameters, you first need to define the tag in the **/base/security/selinux/sepolicy/base/public/parameter.te** file. For example:
```java
type servicectrl_param, parameter_attr
...
...
@@ -114,26 +129,34 @@ Each subsystem defines the system parameters of its own modules, including the s
ohos.servicectrl. u:object_r:servicectrl_param:s0
```
- Grant operation permissions. For example, to grant operation permissions such as map for the init process, add the following content to the **/base/security/selinux/sepolicy/ohos_policy/startup/init/public/init.te** file:
- Granting access permissions for a process
For example, to grant access permissions such as map for the init process, add the following code to the **/base/security/selinux/sepolicy/ohos_policy/startup/init/public/init.te** file:
@@ -145,27 +168,28 @@ Each subsystem defines the system parameters of its own modules, including the s
- A private tag to control system parameter settings.
- A public tag to grant access from all services.
- A public tag to grant access permissions from all services.
- Loading sequence
The following table provides the sequence of loading system parameters.
System parameters are loaded by priority in the specified sequence, as described in Table 5.
**Table 5** Description of the system parameter loading sequence
**Table 5** System parameter loading sequence
| Type| Path| Description|
| -------- | -------- | -------- |
| Kernel parameters | /proc/cmdline | Convert some values of kernel parameters into system parameters. Specifically, convert all **ohospara.xxx=valXXX** parameters to **ohos.boot.xxx=valXXX** parameters.|
| OS system parameters| /system/etc/param/ohos_const/*.para | Load the definition file containing OS constants preferentially. |
| Vendor parameters| /vendor/etc/param/*.para | Load the system parameters defined by vendors with the secondary priority. |
| System parameters| /system/etc/param/*.para | Load the parameters defined by each subsystem. If a system parameter already exists, ignore it.|
| Persistent parameters| /data/parameters/ | If persistent parameters exist, load them at last. Persistent parameters will overwrite the default system parameters that have been loaded.|
| System parameters| /system/etc/param/*.para | Load the system parameters defined by each subsystem. A system parameter will be ignored if it already exists.|
| Persistent parameters| /data/parameters/ | Load persistent parameters, if any, at last. Persistent parameters will overwrite the default system parameters that have been loaded.|
#### System Parameter Tag File Size
#### Tag File Size
If one tag corresponds to more than five system parameters, you need to set the size of the system parameter tag file in **/base/startup/init/services/etc/param/ohos.para.size**. The size value is **512** by default.
If one tag is associated with more than five system parameters, you need to set the size of the system parameter tag file in **/base/startup/init/services/etc/param/ohos.para.size**. The value is **512** by default.
Configuring rule:
The configuring rule is as follows:
System parameter tag = Size
...
...
@@ -178,18 +202,23 @@ startup_init_param=40960
### Constraints
The service management module is available only for the mini system and standard system.
The parameter management subsystem is available only for the mini system and standard system.
## How to Develop
### Use Cases
### Use Case
You can set specific system parameters as needed to meet your service demand.
### Available APIs
### Implementation Method
The parameter management subsystem allows you to manage system parameters by running shell commands or calling **syspara** APIs.
- Shell commands
- Shell command mode
You can operate system parameters directly by using shell commands. This operation mode is available only for the standard system. The following table lists the shell commands.
You can operate system parameters directly by running shell commands. This operation mode is available only for the standard system.
Table 6 is a list of the shell commands.
**Table 6** Description of shell commands
...
...
@@ -200,51 +229,54 @@ You can set specific system parameters as needed to meet your service demand.
| param wait **key** **value** | Waits for the system parameter value of the specified key to match the specified value. Fuzzy match is supported. For example, * indicates any value, and <strong>val</strong>* indicates matching of only the first three val characters.|
| param watch | Observes value change of a system parameter asynchronously.|
- syspara APIs
- syspara API mode
The following table lists the APIs used to obtain system parameter values. The return result is a const string and the free operation is not supported.
Besides shell commands, you can use **syspara** APIs to manage system parameters. The return result is a constant string and the **free** operation is not supported.
Table 7 is a list of the **syspara** APIs.
**Table 7** Description of syspara APIs
| API| Description|
| -------- | -------- |
| int GetParameter(const char\* key, const char\* def, char\* value, unsigned int len) | Obtains system parameters.|
| int SetParameter(const char\* key, const char\* value) | Sets or updates system parameters.|
| const char\* GetDeviceType(void) | Obtains the device type.|
| const char\* GetManufacture(void) | Obtains the device manufacturer.|
| const char\* GetBrand(void) | Obtains the device brand.|
| const char\* GetMarketName(void) | Obtains the device marketing name.|
| const char\* GetProductSeries(void) | Obtains the device series name.|
| const char\* GetProductModel(void) | Obtains the device authentication model.|
| const char\* GetSoftwareModel(void) | Obtains the device software model.|
| const char\* GetHardwareModel(void) | Obtains the device hardware model.|
| const char\* GetHardwareProfile(void) | Obtains the device hardware profile.|
| const char\* GetSerial(void) | Obtains the device serial number (SN).|
| const char\* GetOSFullName(void) | Obtains the operating system name.|
| const char\* GetDisplayVersion(void) | Obtains the software version visible to users.|
| const char\* GetBootloaderVersion(void) | Obtains the bootloader version of this device.|
| const char\* GetSecurityPatchTag(void) | Obtains the security patch tag.|
| const char\* GetAbiList(void) | Obtains the list of application binary interfaces (ABIs) supported on this device.|
| int GetSdkApiVersion(void) | Obtains the SDK API level that matches the current system software.|
| int GetFirstApiVersion(void) | Obtains the first SDK API level of the system software.|
| const char\* GetIncrementalVersion(void) | Obtains the incremental version.|
| const char\* GetManufacture(void) | Obtains the device's manufacturer name.|
| const char\* GetBrand(void) | Obtains the device's brand name.|
| const char\* GetMarketName(void) | Obtains the device's marketing name.|
| const char\* GetProductSeries(void) | Obtains the device's product series name.|
| const char\* GetProductModel(void) | Obtains the device's authentication model.|
| const char\* GetSoftwareModel(void) | Obtains the device's software model.|
| const char\* GetHardwareModel(void) | Obtains the device's hardware model.|
| const char\* GetHardwareProfile(void) | Obtains the device's hardware profile.|
| const char\* GetSerial(void) | Obtains the device's serial number (SN).|
| const char\* GetOSFullName(void) | Obtains the device's OS name.|
| const char\* GetDisplayVersion(void) | Obtains the device's displayed software version.|
| const char\* GetBootloaderVersion(void) | Obtains the device's bootloader version.|
| const char\* GetSecurityPatchTag(void) | Obtains the device's security patch tag.|
| const char\* GetAbiList(void) | Obtains the list of supported application binary interfaces (ABIs).|
| int GetSdkApiVersion(void) | Obtains the SDK API version that matches the current system software.|
| int GetFirstApiVersion(void) | Obtains the first SDK API version of the system software.|
| const char\* GetIncrementalVersion(void) | Obtains the incremental version of the system software.|
| const char\* GetVersionId(void) | Obtains the version ID.|
| const char\* GetBuildType(void) | Obtains the build type.|
| const char\* GetBuildUser(void) | Obtains the build account user name.|
| const char\* GetBuildHost(void) | Obtains the build host name.|
| const char\* GetBuildUser(void) | Obtains the build user.|
| const char\* GetBuildHost(void) | Obtains the build host.|
| const char\* GetBuildTime(void) | Obtains the build time.|
| const char\* GetBuildRootHash(void) | Obtains the buildroot hash value of this version.|
| const char\* GetBuildRootHash(void) | Obtains the buildroot hash value of the current version.|
| const char\* GetOsReleaseType(void) | Obtains the system release type.|
| int GetDevUdid(char \*udid, int size) | Obtains the device identifier (UDID).|
| const char *AclGetSerial(void); | Obtains the device SN (with ACL check).|
| int AclGetDevUdid(char *udid, int size); | Obtains the UDID (with ACL check).|
| int GetDevUdid(char \*udid, int size) | Obtains the device's unique device ID (UDID).|
| const char *AclGetSerial(void); | Obtains the device's SN with ACL check.|
| int AclGetDevUdid(char *udid, int size); | Obtains the device's UDID with ACL check.|
### How to Develop
### Development Procedure
1. System parameter definition
#### Parameter Definition
You can define default system parameters and implement permission control on them by configuring the subsystem or product <strong>.para</strong> and <strong>.para.dac</strong> files.
You can define default system parameters and implement permission control on them by configuring the subsystem or product <strong>.para</strong> and <strong>.para.dac</strong> files.
On a standard system, use the <strong>ohos_prebuilt_para</strong> template to install the configuration file to the <strong>/etc/param/</strong> directory. The following is an example of the GN script:
-On a standard system, use the <strong>ohos_prebuilt_para</strong> template to install the configuration file to the <strong>/etc/param/</strong> directory. The following is an example of the GN script:
@@ -262,7 +294,7 @@ You can set specific system parameters as needed to meet your service demand.
}
```
On a small system, run the <strong>copy</strong> command to copy the corresponding system parameter definition file to the <strong>system/etc/param</strong> directory.
- On a small system, run the <strong>copy</strong> command to copy the corresponding system parameter definition file to the <strong>system/etc/param</strong> directory.
@@ -93,7 +89,6 @@ The **condition** parameter must be in the specified JSON string format. For exa
- The **version** field is mandatory, indicating the supported version of the input condition. Currently, only **V1** is supported.
- The **condition** field is mandatory, indicating the input condition.
- The **and** field is optional, indicating the AND relationship between conditions.
- The **or** field is optional, indicating the OR relationship between conditions.
- The **param** field is mandatory, indicating the parameter name for condition matching. The value must be a string.
- The **op** field is mandatory, indicating the parameter comparison operator for condition matching. The value must be a string. Supported comparison operators include the following: =, >, <,>=, and <=.
- The **value** field is mandatory, indicating the parameter value for condition matching. The value must be a string or an integer.
By default, after a device screen is turned off, OpenHarmony starts the running lock loop detection thread and then enters the hibernation state. For different devices, the mode of turning off the screen is different, which can be closing the lid, setting a timeout, or pressing the power button. Besides, the default hibernation behavior is also different, which can be performing no action, powering off the screen, or entering the hibernation state. To address this issue, OpenHarmony provides the default hibernation behavior customization function, allowing you to customize the default hibernation behavior depending on your hardware specifications.
### Constraints
The configuration paths for battery level customization are subject to the configuration policy.
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate default hibernation behavior customization.
1. Create the `power_manager` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of hibernation behavior configuration](https://gitee.com/openharmony/powermgr_power_manager/tree/master/services/native/profile), and install it in `/vendor/hihope/rk3568/power_manager`. The content is as follows:
```text
profile
├── BUILD.gn
├── power_suspend.json
```
3. Write the custom `power_suspend.json` file that contains the custom default hibernation behavior. The following is an example of hibernation behavior configuration:
```json
{
"powerkey": {
"action": 1,
"delayMs": 0
},
"timeout": {
"action": 1,
"delayMs": 0
},
"lid": {
"action": 1,
"delayMs": 0
},
"switch": {
"action": 1,
"delayMs": 0
}
}
```
**Table 1** Description of hibernation sources
| Hibernation Source| Description|
| -------- | -------- |
| powerkey | Hibernation by power button|
| timeout | Hibernation by timeout|
| lid | Hibernation by lid|
| switch | Hibernation by switch|
**Table 2** Description of the hibernation source configuration
| Item| Description|
| -------- | -------- |
| action | Action to take after the screen is turned off. Set this parameter to an enumerated value. For details, see Table 3.|
| delayMs | Delay, in ms.|
**Table 3** Description of action
| action | Value| Description|
| -------- | -------- | -------- |
| ACTION_NONE | 0 | No action.|
| ACTION_AUTO_SUSPEND | 1 | Automatically entering the sleep mode.|
| ACTION_FORCE_SUSPEND | 2 | Forcibly entering the sleep mode.|
| ACTION_HIBERNATE | 3 | Entering the hibernation state.|
| ACTION_SHUTDOWN | 4 | Shutting down the system.|
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_power_manager/blob/master/services/native/profile/BUILD.gn) file in the default folder of hibernation behavior configuration to pack the `power_suspend.json` file to the `/vendor/etc/power_config` directory. The configuration is as follows:
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
"//vendor/hihope/rk3568/power_manager/profile:wakeup_config" // Add the configuration for building of suspend_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/power_manager/` is the folder path, `profile` is the folder name, and `suspend_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. Customize hibernation sources in the `power_suspend.json` file.
```json
{
"powerkey":{
"action":4,
"delayMs":0
},
"timeout":{
"action":1,
"delayMs":0
},
"lid":{
"action":1,
"delayMs":0
},
"switch":{
"action":1,
"delayMs":0
}
}
```
2. Power on the device, and then press the power button.
The device is powered off.
3. Power on the device again, and then wait for a while.
By default, OpenHarmony provides the power consumption statistics feature. However, the power consumption benchmarks vary according to hardware specifications of different products. To address this issue, OpenHarmony provides the power consumption statistics customization function, allowing you to customize power consumption benchmarks depending on your hardware specifications.
By default, OpenHarmony provides the power consumption statistics feature. However, the power consumption benchmarks vary according to hardware specifications of different products. To address this issue, OpenHarmony provides the power consumption statistics customization function, allowing you to customize power consumption benchmarks depending on your hardware specifications.
OpenHarmony supports multiple wakeup sources, such as the power button, keyboard, and mouse, and provides custom modes for turning on and off these wakeup sources. After a device enters the sleep state, you can turn on the screen and wake up the device by pressing the power button, keyboard, or mouse. However, different products may support different peripherals, for example, stylus or folio keyboard. To address this issue, OpenHarmony provides the wakeup source customization function, allowing you to customize wakeup sources depending on your hardware specifications.
### Constraints
The configuration paths for battery level customization are subject to the configuration policy.
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate wakeup source customization.
1. Create the `power_manager` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of wakeup source configuration](https://gitee.com/openharmony/powermgr_power_manager/tree/master/services/native/profile), and install it in `/vendor/hihope/rk3568/power_manager`. The content is as follows:
```text
profile
├── BUILD.gn
├── power_wakeup.json
```
3. Write the custom `power_wakeup.json` file that contains the custom wakeup sources. The following is an example of wakeup source configuration:
```json
{
"powerkey": {
"enable": true
},
"keyborad": {
"enable": true
},
"mouse": {
"enable": true
},
"touchscreen": {
"enable": true,
"click": 2
},
"touchpad": {
"enable": true
},
"pen": {
"enable": true
},
"lid": {
"enable": true
},
"switch": {
"enable": true
}
}
```
**Table 1** Description of wakeup sources
| Wakeup Source| Description|
| -------- | -------- |
| powerkey | Wakeup by power button|
| keyborad | Wakeup by keyboard|
| mouse | Wakeup by mouse|
| touchscreen | Wakeup by touchscreen|
| touchpad | Wakeup by touchpad|
| pen | Wakeup by stylus|
| lid | Wakeup by lid|
| switch | Wakeup by switch|
**Table 2** Description of the wakeup source configuration
| Item| Type| Description|
| -------- | -------- | -------- |
| enable | bool | Whether to enable wakeup listening|
| click | int | Number of clicks|
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_power_manager/blob/master/services/native/profile/BUILD.gn) file in the default folder of wakeup source configuration to pack the `power_wakeup.json` file to the `/vendor/etc/power_config` directory. The configuration is as follows:
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
"//vendor/hihope/rk3568/power_manager/profile:wakeup_config" // Add the configuration for building of wakeup_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/power_manager/` is the folder path, `profile` is the folder name, and `wakeup_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. Customize wakeup sources in the `power_wakeup.json` file.
```json
{
"powerkey":{
"enable":true
},
"keyborad":{
"enable":true
},
"mouse":{
"enable":true
},
"touchscreen":{
"enable":false,
"click":2
},
"touchpad":{
"enable":false
},
"pen":{
"enable":false
},
"lid":{
"enable":false
},
"switch":{
"enable":false
}
}
```
2. After the device is powered on, press the power button to switch the device to the sleep mode. Then, press the power button again.
The device screen is turned on and the device is woken up.
3. Press the power button to switch the device to the sleep mode, and then press the keyboard.
The device screen is turned on and the device is woken up.
4. Press the power button to switch the device to the sleep mode, and then move the mouse.
The device screen is turned on and the device is woken up.
