The WLAN module is developed based on the Hardware Driver Foundation \(HDF\). It supports cross-OS migration, component adaptation, and modular assembly and compilation. Based on the unified APIs provided by the WLAN module, driver developers of WLAN vendors can adapt their driver code and are capable of creating, disabling, scanning, and connecting to WLAN hotspots. The WLAN driver provides the Hardware Driver Interface \(HDI\) layer with the capabilities of setting and obtaining the device MAC address and setting the transmit power. The following figure shows the framework of the WLAN module:
The WLAN module is developed based on the Hardware Driver Foundation \(HDF\). It supports cross-OS migration, component adaptation, and modular assembly and compilation. Based on the unified APIs provided by the WLAN module, driver developers of WLAN vendors can adapt their driver code and are capable of creating, disabling, scanning, and connecting to WLAN hotspots. The WLAN driver provides the Hardware Device Interface \(HDI\) layer with the capabilities of setting and obtaining the device MAC address and setting the transmit power. The following figure shows the framework of the WLAN module:
@@ -9,7 +9,7 @@ The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes inte
**Display Driver Model**
The display driver model consists of the display common driver layer, SoC adapter layer, and third-party chip driver layer. The display driver model is developed based on the HDF and hides the differences between kernel forms through platform and OSAL APIs so the LCD driver can be migrated between different OSs and chip platforms. The display driver connects to the display common HAL, supports the implementation of Hardware Driver Interfaces \(HDIs\), and provides various driver interfaces for the graphics service through the display HDI.
The display driver model consists of the display common driver layer, SoC adapter layer, and third-party chip driver layer. The display driver model is developed based on the HDF and hides the differences between kernel forms through platform and OSAL APIs so the LCD driver can be migrated between different OSs and chip platforms. The display driver connects to the display common HAL, supports the implementation of Hardware Device Interfaces \(HDIs\), and provides various driver interfaces for the graphics service through the display HDI.
- HDF display driver layer: connects to the display common HAL through the IOService data channel provided by the HDF to receive and process various upper-layer calls in a centralized manner.
- SoC adapter layer: decouples the display driver from the SoC driver, configures parameters related to the chip platform, and passes the calls at the platform driver layer to the LCD driver layer.
@@ -32,7 +32,7 @@ The following uses the acceleration sensor driver on the Hi3516D V300 developmen
1. The sensor host reads the sensor management configuration from the Sensor Host node of the device_info HCS (sensor device information HCS).
2. The sensor host parses the sensor management configuration from the HCB database and associates the corresponding sensor driver.
3. The sensor host loads and initializes the sensor manager driver.
4. The sensor manager driver publishes the sensor hardware driver interfaces (HDIs).
4. The sensor manager driver publishes the sensor hardware device interfaces (HDIs).
5. The sensor host reads the acceleration sensor driver configuration from the Sensor Host node of the device_info HCS.
6. The sensor host loads the acceleration sensor abstract driver and calls the initialization interface to allocate the sensor driver resources and create the data processing queue.
7. The sensor host reads the chipset driver configuration and private configuration of the acceleration sensor from the accel_xxx_config HCS (sensor private configuration HCS).
This section describes how to develop the touchscreen driver based on the input driver model. [Figure 1](#fig6251184817261) shows an overall architecture of the touchscreen driver.
The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Driver Interfaces \(HDIs\) for upper-layer input services to control the touchscreen.
The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Device Interfaces \(HDIs\) for upper-layer input services to control the touchscreen.
**Figure 1** Architecture of the input driver model<aname="fig6251184817261"></a>
<tdclass="cellrowborder"valign="top"width="38.54%"headers="mcps1.2.5.1.2 "><aname="ul100191223919"></a><aname="ul100191223919"></a><ulid="ul100191223919"><li>The sensor, input, and display driver models have been added.</li><li>The MIPI DSI and pulse width modulation (PWM) have been added.</li><li>Hardware Driver Interfaces (HDIs) and Wi-Fi flow control have been added.</li><li>The I/O service grouping feature has been added for the Hardware Driver Foundation (HDF).</li></ul>
<tdclass="cellrowborder"valign="top"width="38.54%"headers="mcps1.2.5.1.2 "><aname="ul100191223919"></a><aname="ul100191223919"></a><ulid="ul100191223919"><li>The sensor, input, and display driver models have been added.</li><li>The MIPI DSI and pulse width modulation (PWM) have been added.</li><li>Hardware Device Interfaces (HDIs) and Wi-Fi flow control have been added.</li><li>The I/O service grouping feature has been added for the Hardware Driver Foundation (HDF).</li></ul>
</td>
<tdclass="cellrowborder"valign="top"width="28.410000000000004%"headers="mcps1.2.5.1.3 "><pid="p460532073911"><aname="p460532073911"></a><aname="p460532073911"></a>Driver loading has been optimized. It can now be accomplished in segmented parts.</p>
@@ -173,7 +173,7 @@ This version has the following updates to OpenHarmony 3.1 Beta.
| Pan-sensor| - Data reporting by common sensors, such as acceleration, gyroscope, and Hall effect sensors, is supported.<br>- The basic functions of vibrators are supported.<br>- The general algorithms and geomagnetic field algorithms are supported.<br>The following requirements are involved:<br>I4WWTG [miscdevice] Peripheral dependency support by miscdevice<br>I4WWTF [Sensor] Peripheral dependency support by sensor<br>I4WWTD [Sensor] Common algorithm interfaces<br>I4MBRQ [sensor] Horizontal intensity and total intensity of the magnetic field<br>I4MBRP (sensor component) Magnetic declination and dip| NA |
| Distributed data management| - Memory JS objects can now be treated as distributed data objects; Distributed relational data management is provided to support data synchronization based on relational tables.<br>- Condition-based data synchronization and subscription capabilities are supported, making data synchronization more accurate.<br>- File upload is supported.<br>- Data encryption and security tiering are supported, and security control is optimized for data transfer. Multi-user synchronization and isolation are supported.<br>The following requirements are involved:<br>I4IBPH [distributed_kv_store] Supplemented the functions of the distributed data service<br>I4MBRS [distributed_kv_store] Cross-device synchronization and subscription of database records based on predicates<br>I4MBRU [RDB] Database encryption<br>I4NZVP [distributed_kv_store] Distributed database JS APIs<br>I4HAMI [data_share_ability] Subscription of cross-application database changes<br>I4NZP6 [RDB] Multi-table query<br>I4FZ6B [RDB] Transaction<br>I4HAMI [data_share_ability] Subscription of cross-application database changes<br>I4PNX7 [Distributed RDB] Data storage<br>I4HAMD [data_share_ability] Data access modes<br>I4H4FH [distributed_kv_store] Data classification and tiering for the distributed database<br>I4H3M8 [New feature] Complex type of distributed data objects<br>I4HAMD [data_share_ability] Data access modes<br>I4PO00 [Distributed RDB] Data synchronization<br>I4OTW6 [distributed_kv_store] InKeys predicate for the distributed database<br>I4RGFY [DataShare] Reconstruction based on the Extension ability and cross-application data sharing on a single device<br>I4H4FR [distributed_kv_store] Multi-user data isolation and sharing<br>I4RGFY [DataShare] Reconstruction based on the Extension ability and cross-application data sharing on a single device<br>I4XXGF [request] File upload| For the mini and small systems:<br>Distributed data objects are now available to small-system devices.<br>The following requirements are involved:<br>I4H3JJ: Distributed objects for small-system devices|
| DFX| Watchdog detection for the system and application is provided. Log collection for native crashes and JS crashes is supported.<br>Abnormal behavior detection is provided for JS applications.<br>System and process status information can be exported. JS applications can obtain the bottom-layer memory, CPU, and VM information.<br>Distributed tracing and debugging are supported.<br>Log, system event, and application event capabilities are enhanced.<br>The following requirements are involved:<br>I4PJE3 [New feature] Hidumper framework and tool for the standard system<br>I4MBRE [hiperf] Performance statistics<br>I4U0KP [profiler] CPU profiler<br>I4PJE5 [New feature] JS application debugging and optimization based on native memory information<br>I4Q6AQ [New feature] Watchdog<br>I4U0JZ [New feature] hisysevent management<br>I4Q6B6 [Enhanced feature] HiTrace JS APIs<br>I4Q6AY [New feature] Detection mode framework and basic detection basic functions| NA |
| Driver| -& Enhanced Hardware Driver Foundation (HDF) capabilities are provided, including HDF Configuration Source (HCS) configuration parsing and power management.<br>- The shared memory queue and on-demand hardware driver interface (HDI) service startup are added to the HDI management framework.<br>- The user-mode platform interfaces are provided for user-mode driver development.<br>- More than 200 HDI interfaces are defined for peripheral modules such as display, audio, camera, sensor, power supply, and USB. The number of device interfaces exceeds 600, providing more hardware access capabilities.<br>The following requirements are involved:<br>I4HPR7 [Enhanced feature] HCS macro parsing interface<br>I4LZZF [Enhanced feature] Synchronous/Asynchronous power management invocation<br>I4QEKH [New feature] Shared memory HDIs<br>I4QEKI [New feature] Driver development tool for standard-system driver development<br>I4QEKZ [New feature] User-mode platform driver interfaces<br>I4QEKL [New feature] Unified platform driver object model built on the HDF<br>I4QELC [New feature] On-demand UHDF process startup<br>I4QEKJ [New feature] HDI adaptation for the Linux-input driver<br>I4QEKM [New feature] Power HDIs<br>I4QEKK [New feature] HDF-based hardware timer driver<br>I4QEKP [New feature] HDF-based light driver<br>I4MBTP [Enhanced feature] Enhanced sensor driver model<br>I4MBTQ [Enhanced feature] Enhanced sensor driver<br>I4MBTR [Enhanced feature] Display HDI reference implementation for the standard system<br>I4MBTS [New feature] More HDF input device capabilities<br>I4QEKP [New feature] HDF based light driver<br>I4QEKQ [New feature] Service-oriented display HDI implementation<br>I4QEL2 [Enhanced feature] Enhanced vibrator driver model<br>I4XXGZ [New feature] HDF based pedometer sensor driver| For the mini and small systems:<br>HCS macro parsing interfaces are provided to reduce the memory usage during compilation.<br>The following requirements are involved:<br>I4TFTB [New feature] HCS macro parsing interfaces for the mini system|
| Driver| -& Enhanced Hardware Driver Foundation (HDF) capabilities are provided, including HDF Configuration Source (HCS) configuration parsing and power management.<br>- The shared memory queue and on-demand hardware device interface (HDI) service startup are added to the HDI management framework.<br>- The user-mode platform interfaces are provided for user-mode driver development.<br>- More than 200 HDI interfaces are defined for peripheral modules such as display, audio, camera, sensor, power supply, and USB. The number of device interfaces exceeds 600, providing more hardware access capabilities.<br>The following requirements are involved:<br>I4HPR7 [Enhanced feature] HCS macro parsing interface<br>I4LZZF [Enhanced feature] Synchronous/Asynchronous power management invocation<br>I4QEKH [New feature] Shared memory HDIs<br>I4QEKI [New feature] Driver development tool for standard-system driver development<br>I4QEKZ [New feature] User-mode platform driver interfaces<br>I4QEKL [New feature] Unified platform driver object model built on the HDF<br>I4QELC [New feature] On-demand UHDF process startup<br>I4QEKJ [New feature] HDI adaptation for the Linux-input driver<br>I4QEKM [New feature] Power HDIs<br>I4QEKK [New feature] HDF-based hardware timer driver<br>I4QEKP [New feature] HDF-based light driver<br>I4MBTP [Enhanced feature] Enhanced sensor driver model<br>I4MBTQ [Enhanced feature] Enhanced sensor driver<br>I4MBTR [Enhanced feature] Display HDI reference implementation for the standard system<br>I4MBTS [New feature] More HDF input device capabilities<br>I4QEKP [New feature] HDF based light driver<br>I4QEKQ [New feature] Service-oriented display HDI implementation<br>I4QEL2 [Enhanced feature] Enhanced vibrator driver model<br>I4XXGZ [New feature] HDF based pedometer sensor driver| For the mini and small systems:<br>HCS macro parsing interfaces are provided to reduce the memory usage during compilation.<br>The following requirements are involved:<br>I4TFTB [New feature] HCS macro parsing interfaces for the mini system|
| USB| - A complete USB service management framework is built, including the host and device modules.<br>- Port switching is supported for switching between different function modes.<br>- USB JS APIs are provided for application development.<br>- USB HDIs are defined and implemented, and standard interfaces for USB driver access are provided.<br>The following requirements are involved:<br>I4MBRK [New feature] JS API implementation for the USB service<br>I4QEKV [New feature] HDI implementation for the USB service<br>I4QEKN [New feature] USB device implementation<br>I4QEKO [New feature] USB host implementation<br>I4QEL6 [New feature] USB port implementation| NA |
| Compilation and building| - Normalized component definition and compilation are added.<br>- A unified compilation framework is provided, including the unified gn template, component configuration, product configuration, build commands, and build process.<br>- Native SDK compilation and release are supported.<br>- The Kconfig framework is supported.<br>- The hb capabilities are enhanced, including using the hb compilation entry in a unified manner, displaying build logs by level, and supporting hb command installation, integration, and extension.<br>- gn coding specifications and best practice are provided.| The feature changes for the mini and small systems are the same as those for the standard system.|
| Test| - The automated test framework is added to support the compilation and running of basic unit/UI test scripts.<br>- The wukong tool is provided to support pressure testing of random event injection at the level of the entire system or a single application.<br>-& The SmartPerf tool is added to collect and display basic performance data such as FPS, CPU, and memory data.<br>- The test scheduling framework is enhanced to support automatic case execution configuration and execution configuration management.<br>- The DCTS compatibility test suite is provided to support the DSoftBus and distributed data compatibility test.<br>-& The ACTS and HATS compatibility test suites are enhanced, covering external public JS APIs and HDF APIs in OpenHarmony 3.1 Release.<br>The following requirements are involved:<br>I4XXCR [Test framework] UI automation test<br>I4XXCV [Test framework] TS developer test framework<br>I4XXCW [Test framework] JS application developer test framework<br>I4XXD0 [Test framework] Executor device management<br>I4XXCX [Test framework] Test pipeline test suite execution report<br>I4XXCZ [Test framework] Test case configuration management<br>I4XXD0 [Test framework] Executor device management<br>I4XGLQ [New feature] UI random pressure test tool<br>I4XXD7 [Authentication test] DCTS 3.1 distributed compatibility test suite| NA |
