The codec Hardware Device Interface (HDI) driver framework is implemented based on OpenHarmony Hardware Driver Foundation (HDF). The HDI driver framework implements the video hardware codec driver based on OpenMAX. It provides APIs for the upper-layer media services to obtain component encoding and decoding capabilities, create a component, set parameters, transfer data, and destroy a component. The codec driver can encode video data in YUV or RGB format to H.264 or H.265 format, and decode raw stream data from H.264 or H.265 format to YUV or RGB format.
The OpenHarmony codec Hardware Device Interface (HDI) driver framework implements the video hardware codec driver based on OpenMAX. It provides APIs for the upper-layer media services to obtain component encoding and decoding capabilities, create a component, set parameters, transfer data, and destroy a component. The codec driver can encode video data in YUV or RGB format to H.264 or H.265 format, and decode raw stream data from H.264 or H.265 format to YUV or RGB format. This document describes the codec functionality developed based on the OpenHarmony Hardware Driver Foundation (HDF).
The figure below shows the codec HDI driver framework.
The codec HDI driver framework is implemented based on the HDF. The figure below shows the codec HDI driver framework.
**Figure 1** Codec HDI driver framework
**Figure 1** Codec HDI driver framework
...
@@ -16,7 +16,7 @@ The figure below shows the codec HDI driver framework.
...
@@ -16,7 +16,7 @@ The figure below shows the codec HDI driver framework.
- Codec HDI Adapter: HDI implementation layer, which implements HDI APIs and interacts with OpenMAX Integration layer (IL).
- Codec HDI Adapter: HDI implementation layer, which implements HDI APIs and interacts with OpenMAX Integration layer (IL).
- OpenMAX IL interface: provides OpenMAX IL APIs to directly interact with the codec HDI driver.
- OpenMAX IL interface: provides OpenMAX IL APIs to directly interact with the codec HDI driver.
- Vendor Impl: vendor adaptation layer, which is the OpenMAX implementation layer adapted by each vendor.
- Vendor Impl: vendor adaptation layer, which is the OpenMAX implementation layer adapted by each vendor.
- Codec Hardware: hardware coding and decoding device.
- Codec Hardware: hardware decoding device.
### Basic Concepts
### Basic Concepts
Before you get started, understand the following concepts:
Before you get started, understand the following concepts:
...
@@ -39,7 +39,7 @@ Before you get started, understand the following concepts:
...
@@ -39,7 +39,7 @@ Before you get started, understand the following concepts:
- Component
- Component
An OpenMAX IL component, which is an abstraction of modules in video streams. The components in this document refer to codec components used for video encoding and decoding.
An OpenMAX IL component, which is an abstraction of modules in video streams. The components in this document refer to codec components for video encoding and decoding.
### Constraints
### Constraints
...
@@ -56,20 +56,20 @@ The codec module implements hardware encoding and decoding of video data. It con
...
@@ -56,20 +56,20 @@ The codec module implements hardware encoding and decoding of video data. It con
| int32_t (*UseBuffer)(struct CodecComponentType *self, uint32_t portIndex, struct OmxCodecBuffer *buffer) | Requests a port buffer for the component. |
| int32_t (*UseBuffer)(struct CodecComponentType *self, uint32_t portIndex, struct OmxCodecBuffer *buffer) | Specifies the buffer of a component port. |
@@ -84,11 +84,11 @@ The codec module implements hardware encoding and decoding of video data. It con
...
@@ -84,11 +84,11 @@ The codec module implements hardware encoding and decoding of video data. It con
For more information, see [codec](https://gitee.com/openharmony/drivers_peripheral/tree/master/codec).
For more information, see [codec](https://gitee.com/openharmony/drivers_peripheral/tree/master/codec).
### Development Procedure
### How to Develop
The codec HDI driver development procedure is as follows:
The codec HDI driver development procedure is as follows:
#### Registering and Initializing the Driver
#### Registering and Initializing the Driver
Define the **HdfDriverEntry** structure (which defines the driver initialization method) and fill in the **g_codecComponentDriverEntry** structure to implement the pointers in **Bind()**, **Init()**, and **Release()**.
Define the **HdfDriverEntry** structure (which defines the driver initialization method) and fill in the **g_codecComponentDriverEntry** structure to implement the **Bind()**, **Init()**, and **Release()** pointers.
```c
```c
structHdfDriverEntryg_codecComponentDriverEntry={
structHdfDriverEntryg_codecComponentDriverEntry={
...
@@ -133,7 +133,7 @@ HDF_INIT(g_codecComponentDriverEntry); // Register HdfDriverEntry of the codec H
...
@@ -133,7 +133,7 @@ HDF_INIT(g_codecComponentDriverEntry); // Register HdfDriverEntry of the codec H
}
}
```
```
-**HdfCodecComponentTypeDriverInit**: loads the attribute configuration in the HDF Configuration Source (HCS).
-**HdfCodecComponentTypeDriverInit**: loads the attribute configuration from the HDF configuration source (HCS).
@@ -170,11 +170,12 @@ The HCS consists of the following:
...
@@ -170,11 +170,12 @@ The HCS consists of the following:
- Device configuration
- Device configuration
- Configuration of the supported components
- Configuration of the supported components
You need to configure the driver node, loading sequence, and service name. For details about the HCS syntax, see [Configuration Management](driver-hdf-manage.md).
The HCS includes the driver node, loading sequence, and service name. For details about the HCS syntax, see [Configuration Management](driver-hdf-manage.md).
The following uses the RK3568 development board as an example. The configuration files of the standard system are in the **vendor/hihope/rk3568/hdf_config/uhdf/** directory.
Configuration file Path of the standard system:
vendor/hihope/rk3568/hdf_config/uhdf/
1.Configure the device.
1.Device configuration
Add the **codec_omx_service** configuration to **codec_host** in **device_info.hcs**. The following is an example:
Add the **codec_omx_service** configuration to **codec_host** in **device_info.hcs**. The following is an example:
```c
```c
...
@@ -188,31 +189,31 @@ The following uses the RK3568 development board as an example. The configuration
...
@@ -188,31 +189,31 @@ The following uses the RK3568 development board as an example. The configuration
priority = 100; // Priority.
priority = 100; // Priority.
moduleName = "libcodec_hdi_omx_server.z.so"; // Dynamic library of the driver.
moduleName = "libcodec_hdi_omx_server.z.so"; // Dynamic library of the driver.
serviceName = "codec_hdi_omx_service"; // Service name of the driver.
serviceName = "codec_hdi_omx_service"; // Service name of the driver.
@@ -238,7 +239,7 @@ The following uses the RK3568 development board as an example. The configuration
...
@@ -238,7 +239,7 @@ The following uses the RK3568 development board as an example. The configuration
### Development Example
### Development Example
After completing codec module driver adaptation, use the HDI APIs provided by the codec module for further development. The codec HDI provides the following features:
After completing codec module driver adaptation, use the HDI APIs provided by the codec module for further development. The codec HDI provides the following features:
1. Provides codec HDI APIs for video services to implement encoding and decoding for video services.
1. Provides codec HDI APIs for video services to implement encoding and decoding of video services.
2. Provides standard interfaces for device developers to ensure that the OEM vendors comply with the HDI adapter standard. This promises a healthy evolution of the ecosystem.
2. Provides standard interfaces for device developers to ensure that the OEM vendors comply with the HDI adapter standard. This promises a healthy evolution of the ecosystem.
The development procedure is as follows:
The development procedure is as follows:
...
@@ -247,7 +248,7 @@ The development procedure is as follows:
...
@@ -247,7 +248,7 @@ The development procedure is as follows:
2. Set codec parameters and information such as the video width, height, and bit rate.
2. Set codec parameters and information such as the video width, height, and bit rate.
3. Apply for input and output buffers.
3. Apply for input and output buffers.
4. Flip codec buffers, enable the component to enter the **OMX_Executing** state, and process the callbacks.
4. Flip codec buffers, enable the component to enter the **OMX_Executing** state, and process the callbacks.
5. Deinitialize the interface instance, destroy the buffers, close the component, and releases all interface instances.
5. Deinitialize the interface instance, destroy the buffers, close the component, and releases all interface objects.
#### Initializing the Driver
#### Initializing the Driver
Initialize the interface instance and callbacks, and create a component.
Initialize the interface instance and callbacks, and create a component.
...
@@ -351,7 +352,7 @@ Perform the following steps:
...
@@ -351,7 +352,7 @@ Perform the following steps:
1. Use **UseBuffer()** to apply for input and output buffers and save the buffer IDs. The buffer IDs can be used for subsequent buffer flipping.
1. Use **UseBuffer()** to apply for input and output buffers and save the buffer IDs. The buffer IDs can be used for subsequent buffer flipping.
2. Check whether the corresponding port is enabled. If not, enable the port first.
2. Check whether the corresponding port is enabled. If not, enable the port first.
3. Use **SendCommand()** to change the component status to **OMX_StateIdle**, and wait until the operation result is obtained.
3. Use **SendCommand()** to change the component status to OMX_StateIdle, and wait until the operation result is obtained.
The RK3568 development board does not support data framing. Therefore, you need to manually divide the data into frames. Data is divided from code 0x000001 or 0x00000001 and sent to the server for processing. The sample code is as follows:
Automatic framing is not supported in rk OMX decoding. Therefore, you need to manually divide data into frames. Currently, data is divided into frames from code 0x000001 or 0x00000001 and sent to the server for processing. The sample code is as follows:
-**EventHandler**: Called when a command is executed. For example, when the command for changing the component state from **OMX_StateIdle** to **OMX_StateExecuting** is executed, this callback is invoked to return the result.
-**EventHandler**: Called when a command is executed. For example, when the command for changing the component state from **OMX_StateIdle** to **OMX_StateExecuting** is executed, this callback is invoked to return the result.
-**EmptyBufferDone**: Called when the input data is consumed. If the client needs to fill data to encode or decode, it must call **EmptyThisBuffer()** again.
-**EmptyBufferDone**: Called when the input data is consumed. If the client needs to fill in data to encode or decode, call **EmptyThisBuffer()**.
-**FillBufferDone**: Called when the output data is filled. If the client needs to read the encoded or decoded data, it must call **FillThisBuffer()** again.
-**FillBufferDone**: Called when the output data is filled. If the client needs to read the encoded or decoded data, call **FillThisBuffer()**.
Change the component state to **OMX_StateIdle**, release the input and output buffers, change the component state to **OMX_StateLoaded**, and call **DestoryComponent** to destroy the component.
Change the component state to IDLE, release the input and output buffers, change the component state to **OMX_StateLoaded**, and call **DestoryComponent** to destroy the component.
##### Example of Releasing Buffers
##### Example of Releasing Buffers
...
@@ -719,7 +721,7 @@ OpenMAX does not support framing.
...
@@ -719,7 +721,7 @@ OpenMAX does not support framing.
**Solution**
**Solution**
Pass in one frame at a time when **EmptyThisBuffer** is call.
Transfer data frame by frame when **EmptyThisBuffer** is called.
## Only Green Screen Displayed During the Decoding Process
## Only Green Screen Displayed During the Decoding Process
...
@@ -749,11 +751,11 @@ After the generated video stream (H.264 stream) is written to a file, the video
...
@@ -749,11 +751,11 @@ After the generated video stream (H.264 stream) is written to a file, the video
**Solution**
**Solution**
View the **codec_host** log generated during encoding, search for "encode params init settings", and check for incorrect parameters. If **framerate** is **0**, **xFramerate** is incorrectly set. In this case, move the framerate leftwards by 16 bits.
View the **codec_host** log generated during encoding, search for "encode params init settings", and check for incorrect parameters. If **framerate** is **0**, **xFramerate** is incorrectly set. In this case, move the framerate leftwards by 16 bits.
Check and correct the setting of **OMX_VIDEO_PARAM_AVCTYPE**.
Check the value of **OMX_VIDEO_PARAM_AVCTYPE**, and set it correctly.
# Reference
# Reference
For more information, see [codec](https://gitee.com/openharmony/drivers_peripheral/tree/master/codec).
For more information, see [Codec](https://gitee.com/openharmony/drivers_peripheral/tree/master/codec).
The light driver model provides APIs for the upper-layer light hardware service layer to control lights, including obtaining the light type, setting the lighting mode and blinking effect, and turning on or off a light. This model implements functionalities such as cross-OS migration and differentiated configurations based on the Hardware Driver Foundation (HDF) to achieve the goal of "one-time development for cross-system deployment" of the light driver.
The light driver model provides APIs for the upper-layer light hardware service layer to control lights, including obtaining the light type, setting the lighting mode and blinking effect, and turning on or off a light. This model implements cross-OS porting and differentiated configurations based on the Hardware Driver Foundation (HDF) to achieve the goal of "one-time development for cross-system deployment" of the light driver.
The figure below shows the light driver model.
The figure below shows the light driver model.
...
@@ -21,14 +21,14 @@ The figure below shows how the light driver works.
...
@@ -21,14 +21,14 @@ The figure below shows how the light driver works.
The following uses the Hi3516D V300 development board powered by the standard system as an example to describe how the light driver works.
The following describes how the light module driver loads and starts on a Hi3516D V300 board that runs the standard system.
1. The light driver reads the light device management configuration from **Light Host** in the **device_info.hcs** file.
1. The Device Manager reads the Light device management configuration from the **device_info.hcs** file.
2. The light driver reads the light data configuration from the **light_config.hcs** file.
2. The Device Manager reads the light data configuration from the **light_config.hcs** file.
3. The light driver parses the light device management configuration and associates with the corresponding device driver.
3. The HCS Parser parses the light device management configuration, loads the Light Host, and controls the Host to load the driver.
4. The light proxy delivers an instruction to the light stub.
4. The Light Proxy obtains the light HDI service instance and calls the Light Stub over Inter-Process Communication (IPC).
5. The light stub delivers an instruction to the light controller.
5. The Light Stub processes IPC-related service logic and calls the Light Controller after parameter deserialization.
6. The light abstract driver interface is started.
6. The Light Controller implements the HDI APIs and calls the Light Abstract Driver APIs to operate the light devices.
## Development Guidelines
## Development Guidelines
...
@@ -38,33 +38,32 @@ Light control is widely used in daily life. For example, a light is blinking whe
...
@@ -38,33 +38,32 @@ Light control is widely used in daily life. For example, a light is blinking whe
### Available APIs
### Available APIs
The light driver model provides APIs to obtain information about all the lights in the system and dynamically set the blinking mode and duration. The light hardware service calls the **GetLightInfo** method to obtain basic information about the light and calls the **TurnOnLight** method to make the light blinking. The table below describes the APIs of the light driver model.
The light driver model provides APIs for obtaining information about all the lights in the system and dynamically setting the blinking mode and duration. The light hardware service calls **GetLightInfo()** to obtain the basic light information, calls **TurnOnLight()** to set the blinking effect, and calls **TurnOffLight()** to turn off lights. The following table describes the APIs of the light driver model.
| int32_t (*GetLightInfo)(struct LightInfo **lightInfo, uint32_t *count) | Obtains information about all lights in the system. <br/>- **lightInfo** indicates the double pointer to the basic light information. <br/>- **count** indicates the pointer to the number of lights. |
| int32_t (*GetLightInfo)([out] struct LightInfo **lightInfo, [out] uint32_t *count) | Obtains information about all types of lights in the system. <br>**lightInfo** indicates the double pointer to the light information obtained. <br>**count** indicates the pointer to the number of lights.|
| int32_t (*TurnOnLight)(uint32_t lightId, struct LightEffect *effect) | Turns on available lights in the list based on the specified light type. <br/>**lightId** indicates the light type, and **effect** indicates the pointer to the blinking effect. |
| int32_t (*TurnOnLight)([in] uint32_t lightId, [in] struct LightEffect *effect) | Turns on available lights in the list based on the specified light type. <br>**lightId** indicates the light type, and **effect** indicates the pointer to the light effect.|
| int32_t (*TurnOffLight)(uint32_t lightId) | Turns off available lights in the light list based on the specified light type. <br/>**lightId** indicates the light type. |
| int32_t (*TurnOffLight)([in] uint32_t lightId) | Turns off available lights in the list based on the specified light type. |
### How to Develop
### Development Procedure
1. Based on the HDF and the driver entry, complete the light abstract driver development (using the **Bind**, **Init**, **Release**, and **Dispatch** functions), resource configuration, and HCS parsing. Configure the light driver device information.
1. Based on the HDF and the driver entry, complete the light abstract driver development (using the **Bind**, **Init**, **Release**, and **Dispatch** functions), resource configuration, and HCS parsing.
- Call **HDF_INIT** to register the driver entry with the HDF. Generally, the HDF calls the **Bind** function and then the **Init** function to load the driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit.
- Call **HDF_INIT** to register the driver entry with the HDF. Generally, the HDF calls the **Bind** function and then the **Init** function to load the driver. If **Init** fails to be called, the HDF calls **Release** to release driver resources and exit.
The light driver model uses HDF configuration source (HCS). For details about HCS fields, see [Configuration Management](../driver/driver-hdf-manage.md).
- The light driver model uses HDF configuration source (HCS). For details about HCS fields, see [Configuration Management](driver-hdf-manage.md). The light driver entry is defined as follows:
The light driver entry is defined as follows:
```c
```c
/* Register the light entry data structure object. */
/* Register the light entry data structure object. */
struct HdfDriverEntry g_lightDriverEntry = {
struct HdfDriverEntry g_lightDriverEntry = {
.moduleVersion = 1, // Light module version.
.moduleVersion = 1, // Version of the light module.
.moduleName = "HDF_LIGHT", // Light module name, which must be the same as the value of moduleName in the device_info.hcs file.
.moduleName = "HDF_LIGHT", // Light module name, which must be the same as the value of moduleName in the device_info.hcs file.
.Bind = BindLightDriver, // BInd the light driver.
.Bind = BindLightDriver, // Bind() of the light driver.
.Init = InitLightDriver, // Initialize the light driver.
.Init = InitLightDriver, // Init() of the light driver.
.Release = ReleaseLightDriver, // Release the light resources.
.Release = ReleaseLightDriver, // Release() of the light driver.
};
};
/* Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls Bind() and then Init() to load the driver. If Init() fails to be called, the HDF will call Release() to release resources and exit. */
/* Call HDF_INIT to register the driver entry with the HDF. */
HDF_INIT(g_lightDriverEntry);
HDF_INIT(g_lightDriverEntry);
```
```
...
@@ -122,7 +121,7 @@ The light driver model provides APIs to obtain information about all the lights
...
@@ -122,7 +121,7 @@ The light driver model provides APIs to obtain information about all the lights
}
}
/* Initialize work items. */
/* Initialize work items. */
if (HdfWorkInit(&drvData->work, LightWorkEntry, (void*)drvData) != HDF_SUCCESS) {
if (HdfWorkInit(&drvData->work, LightWorkEntry, (void*)drvData) != HDF_SUCCESS) {
HDF_LOGE("%s: init workQueue fail!", __func__);
HDF_LOGE("%s: init work fail!", __func__);
return HDF_FAILURE;
return HDF_FAILURE;
}
}
/* Parse the HCS. */
/* Parse the HCS. */
...
@@ -160,20 +159,24 @@ The light driver model provides APIs to obtain information about all the lights
...
@@ -160,20 +159,24 @@ The light driver model provides APIs to obtain information about all the lights
}
}
```
```
- The light device management module publishes light device APIs in the system. During the system startup process, the HDF loads the device management driver based on **Light Host** in the HCS.
- The light device management module is responsible for publishing light device APIs in the system. During the system startup process, the HDF loads the device management driver based on **Light Host** in the HCS.
```
```c
/* Light device HCS */
/* HCS of the light device. */
device_light :: device {
light :: host {
device0 :: deviceNode {
hostName = "light_host";
policy = 2; // Policy for the driver to publish services. (0: The driver does not provide services. 1: The driver publishes services for the kernel space. 2: The driver publishes services for both the kernel space and user space.)
device_light :: device {
priority = 100; // Light driver startup priority. The value ranges from 0 to 200. A larger value indicates a lower priority. The value 100 is recommended. If the priorities are the same, the device loading sequence cannot be ensured.
device0 :: deviceNode {
preload = 0; // Whether to load the driver on demand. The value 0 means to load the driver on demand; the value 2 means the opposite.
policy = 2; // Policy for the driver to publish services. If the value is 0, the driver does not publish services. If the value is 1, the driver publishes services to the kernel space. If the value is 2, the driver publishes services to both the kernel space and user space.
permission = 0664; // Permission for the driver to create a device node.
priority = 100; // Priority (0–200) for starting the light driver. A larger value indicates a lower priority. The recommended value is 100. If the priorities are the same, the device loading sequence is not ensured.
moduleName = "HDF_LIGHT"; // Light driver name. The value of this field must be the same as that of moduleName in the HdfDriverEntry structure.
preload = 0; // The value 0 means to load the driver by default during the startup of the system. The value 2 means the opposite.
serviceName = "hdf_light"; // Unique name of the service published by the driver.
permission = 0664; // Permission for the device node created.
deviceMatchAttr = "hdf_light_driver"; // Keyword for matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
moduleName = "HDF_LIGHT"; // Light driver name. The value must be the same as the value of moduleName in the driver entry structure.
serviceName = "hdf_light"; // Service published by the light driver. The service name must be unique.
deviceMatchAttr = "hdf_light_driver"; // Keyword for matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
}
}
}
}
```
```
2. Parse the device attribute information and registers, and register them with the light device management module.
2. Parse the device attribute information and registers, and register them with the light device management module.
...
@@ -193,34 +196,35 @@ The light driver model provides APIs to obtain information about all the lights
...
@@ -193,34 +196,35 @@ The light driver model provides APIs to obtain information about all the lights
}
}
for(i=0;i<drvData->lightNum;++i){
for(i=0;i<drvData->lightNum;++i){
.....
.....
/* Types are used as subscripts to create space. */
/* Types are used as subscripts to create space. */
3.Call related APIs to obtain the light type, turn on and off lights, and create and delete the timer based on the blinking mode.
3.Implement the APIs for obtaining the light type, setting the blinking mode, turning on and off lights, and creating and destroying a timer based on the blinking mode.
```c
```c
/* Call GetAllLightInfo() to obtain the light type. Call TurnOnLight() to enable the blinking mode.
/* Call GetAllLightInfo() to obtain the light types, call TurnOnLight() to turn on lights,
/* Receive the lightBrightness value passed in. Bits 24 to 31 are extension bits, bits 16 to 23 indicate red, bits 8 to 15 indicate green, and bits 0 to 7 indicate blue. If lightBrightness is not 0, enable the light in the specified color.
/* Receive the lightBrightness value passed in. Bits 24 to 31 are extension bits, bits 16 to 23 indicate red, bits 8 to 15 indicate green, and bits 0 to 7 indicate blue. If lightBrightness is not 0, turn on the light in the specified color.
Set the light brightness to a value ranging from 0 to 255 if supported. */
Set the light brightness to a value ranging from 0 to 255 if supported. */
@@ -70,7 +70,7 @@ The USB Device DDK provides the capability of developing USB drivers on the devi
...
@@ -70,7 +70,7 @@ The USB Device DDK provides the capability of developing USB drivers on the devi
- The Adapter module is provided by the composite device configuration driver and common function driver.
- The Adapter module is provided by the composite device configuration driver and common function driver.
## How to Develop
## Development Guidelines
The USB driver development in kernel mode is complex. Therefore, you need to have a deep understanding of the USB protocol. The USB DDK is introduced to help you to develop USB drivers in user mode more conveniently.
The USB driver development in kernel mode is complex. Therefore, you need to have a deep understanding of the USB protocol. The USB DDK is introduced to help you to develop USB drivers in user mode more conveniently.
...
@@ -84,69 +84,69 @@ The following table lists the APIs related to USB host driver development (commo
...
@@ -84,69 +84,69 @@ The following table lists the APIs related to USB host driver development (commo
**Table 1** APIs for USB host driver development (common mode)
**Table 1** APIs for USB host driver development (common mode)
| API| Description|
| API| Description|
| -------- | -------- |
| -------- | -------- |
| int32_t UsbInitHostSdk(struct UsbSession \*\*session); | Initializes the USB host driver DDK.|
| int32_t UsbInitHostSdk(struct UsbSession \*\*session); | Initializes the USB host driver DDK.|
| const struct UsbInterface \*UsbClaimInterface(const<br>struct UsbSession \*session, uint8_t busNum, uint8_t<br>usbAddr, uint8_t interfaceIndex); | Obtains a USB interface.|
| const struct UsbInterface \*UsbClaimInterface(const<br>struct UsbSession \*session, uint8_t busNum, uint8_t<br>usbAddr, uint8_t interfaceIndex); | Obtains a USB interface.|
| UsbInterfaceHandle \*UsbOpenInterface(const struct<br>UsbInterface \*interfaceObj); | Opens a USB interface.|
| UsbInterfaceHandle \*UsbOpenInterface(const struct<br>UsbInterface \*interfaceObj); | Opens a USB interface.|
| int32_t UsbGetPipeInfo(const UsbInterfaceHandle<br>\*interfaceHandle, uint8_t settingIndex, uint8_t pipeId,<br>struct UsbPipeInfo \*pipeInfo); | Obtains USB pipe information.|
| int32_t UsbGetPipeInfo(const UsbInterfaceHandle<br>\*interfaceHandle, uint8_t settingIndex, uint8_t pipeId,<br>struct UsbPipeInfo \*pipeInfo); | Obtains USB pipe information.|
| struct UsbRequest \*UsbAllocRequest(const<br>UsbInterfaceHandle \*interfaceHandle, int32_t isoPackets<br>, int32_t length); | Allocates a request object.|
| struct UsbRequest \*UsbAllocRequest(const<br>UsbInterfaceHandle \*interfaceHandle, int32_t isoPackets<br>, int32_t length); | Allocates a request object.|
| int32_t UsbFillRequest(const struct UsbRequest<br>\*request, const UsbInterfaceHandle \*interfaceHandle,<br>const struct UsbRequestParams \*params); | Fills in a request.|
| int32_t UsbFillRequest(const struct UsbRequest<br>\*request, const UsbInterfaceHandle \*interfaceHandle,<br>const struct UsbRequestParams \*params); | Fills in a request.|
| int32_t UsbSubmitRequestSync(const struct UsbRequest<br>\*request); | Sends a synchronous request.|
| int32_t UsbSubmitRequestSync(const struct UsbRequest<br>\*request); | Sends a synchronous request.|
The following table lists the APIs related to USB host driver development (expert mode). For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/host/usb_raw_api.h).
The following table lists the APIs related to USB host driver development (expert mode). For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/host/usb_raw_api.h).
**Table 2** APIs for USB host driver development (expert mode)
**Table 2** APIs for USB host driver development (expert mode)
| API| Description|
| API| Description|
| -------- | -------- |
| -------- | -------- |
| int32_t UsbRawInit(struct UsbSession \*\*session); | Initializes the USB raw APIs.|
| int32_t UsbRawInit(struct UsbSession \*\*session); | Initializes the USB raw APIs.|
| UsbRawHandle \*UsbRawOpenDevice(const struct<br>UsbSession \*session, uint8_t busNum, uint8_t<br>usbAddr); | Opens a USB device.|
| UsbRawHandle \*UsbRawOpenDevice(const struct<br>UsbSession \*session, uint8_t busNum, uint8_t<br>usbAddr); | Opens a USB device.|
| int32_t UsbRawSendControlRequest(const struct<br>UsbRawRequest \*request, const UsbRawHandle<br>\*devHandle, const struct UsbControlRequestData<br>\*requestData); | Performs a control transfer synchronously.|
| int32_t UsbRawSendControlRequest(const struct<br>UsbRawRequest \*request, const UsbRawHandle<br>\*devHandle, const struct UsbControlRequestData<br>\*requestData); | Performs a control transfer synchronously.|
| int32_t UsbRawSendBulkRequest(const struct<br>UsbRawRequest \*request, const UsbRawHandle<br>\*devHandle, const struct UsbRequestData<br>\*requestData); | Performs a bulk transfer synchronously.|
| int32_t UsbRawSendBulkRequest(const struct<br>UsbRawRequest \*request, const UsbRawHandle<br>\*devHandle, const struct UsbRequestData<br>\*requestData); | Performs a bulk transfer synchronously.|
| int32_t UsbRawSendInterruptRequest(const struct<br>UsbRawRequest \*request, const UsbRawHandle<br>\*devHandle, const struct UsbRequestData<br>\*requestData); | Performs an interrupt transfer synchronously.|
| int32_t UsbRawSendInterruptRequest(const struct<br>UsbRawRequest \*request, const UsbRawHandle<br>\*devHandle, const struct UsbRequestData<br>\*requestData); | Performs an interrupt transfer synchronously.|
| int32_t UsbRawGetConfigDescriptor(const UsbRawDevice<br>\*rawDev, uint8_t configIndex, struct<br>UsbRawConfigDescriptor \*\*config); | Obtains the configuration descriptor of a device.|
| int32_t UsbRawGetConfigDescriptor(const UsbRawDevice<br>\*rawDev, uint8_t configIndex, struct<br>UsbRawConfigDescriptor \*\*config); | Obtains the configuration descriptor of a device.|
| int32_t UsbRawFillInterruptRequest(const struct UsbRawRequest<br>\*request, const UsbRawHandle \*devHandle, const struct<br>UsbRawFillRequestData \*fillData); | Fills in an interrupt transfer request.|
| int32_t UsbRawFillInterruptRequest(const struct UsbRawRequest<br>\*request, const UsbRawHandle \*devHandle, const struct<br>UsbRawFillRequestData \*fillData); | Fills in an interrupt transfer request.|
| int32_t UsbRawFillIsoRequest(const struct UsbRawRequest<br>\*request, const UsbRawHandle \*devHandle, const struct<br>UsbRawFillRequestData \*fillData); | Fills in an isochronous transfer request.|
| int32_t UsbRawFillIsoRequest(const struct UsbRawRequest<br>\*request, const UsbRawHandle \*devHandle, const struct<br>UsbRawFillRequestData \*fillData); | Fills in an isochronous transfer request.|
| int32_t UsbRawSubmitRequest(const struct UsbRawRequest<br>\*request); | Submits a transfer request.|
| int32_t UsbRawSubmitRequest(const struct UsbRawRequest<br>\*request); | Submits a transfer request.|
| int32_t UsbRawCancelRequest(const struct UsbRawRequest<br>\*request); | Cancels a transfer request.|
| int32_t UsbRawCancelRequest(const struct UsbRawRequest<br>\*request); | Cancels a transfer request.|
| int32_t UsbRawHandleRequests(const UsbRawHandle<br>\*devHandle); | Handles a transfer request event.|
| int32_t UsbRawHandleRequests(const UsbRawHandle<br>\*devHandle); | Handles a transfer request event.|
The following table lists the APIs for USB device management on the device side. For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/device/usbfn_device.h).
The following table lists the APIs for USB device management on the device side. For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/device/usbfn_device.h).
**Table 3** APIs for USB device management on the device side
**Table 3** APIs for USB device management on the device side
| API| Description|
| API| Description|
| -------- | -------- |
| -------- | -------- |
| const struct UsbFnDevice \*UsbFnCreateDevice(const<br>char \*udcName, const struct UsbFnDescriptorData<br>\*descriptor); | Creates a USB device.|
| const struct UsbFnDevice \*UsbFnCreateDevice(const<br>char \*udcName, const struct UsbFnDescriptorData<br>\*descriptor); | Creates a USB device.|
| int32_t UsbFnRemoveDevice(struct UsbFnDevice<br>\*fnDevice); | Deletes a USB device.|
| int32_t UsbFnRemoveDevice(struct UsbFnDevice<br>\*fnDevice); | Deletes a USB device.|
| const struct UsbFnDevice \*UsbFnGetDevice(const char<br>\*udcName); | Obtains a USB device.|
| const struct UsbFnDevice \*UsbFnGetDevice(const char<br>\*udcName); | Obtains a USB device.|
The following table lists the APIs for USB interface definition on the device side. For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/device/usbfn_interface.h).
The following table lists the APIs for USB interface definition on the device side. For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/device/usbfn_interface.h).
**Table 4** APIs for USB interface definition on the device side
**Table 4** APIs for USB interface definition on the device side
The following table lists the APIs for USB data request on the device side. For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/device/usbfn_request.h).
The following table lists the APIs for USB data request on the device side. For details about the API definitions, see the [source code](https://gitee.com/openharmony/drivers_peripheral/blob/master/usb/interfaces/ddk/device/usbfn_request.h).
**Table 5** APIs for USB data request on the device side
**Table 5** APIs for USB data request on the device side
| API| Description|
| API| Description|
| -------- | -------- |
| -------- | -------- |
| struct UsbFnRequest<br>\*UsbFnAllocCtrlRequest(UsbFnInterfaceHandle handle,<br>uint32_t len); | Allocates a control transfer request.|
| struct UsbFnRequest<br>\*UsbFnAllocCtrlRequest(UsbFnInterfaceHandle handle,<br>uint32_t len); | Allocates a control transfer request.|
| struct UsbFnRequest \*UsbFnAllocRequest(UsbFnInterfaceHandle handle,<br>uint8_t pipe, uint32_t len); | Allocates a data request.|
| struct UsbFnRequest \*UsbFnAllocRequest(UsbFnInterfaceHandle handle,<br>uint8_t pipe, uint32_t len); | Allocates a data request.|
| int32_t UsbFnFreeRequest(struct UsbFnRequest \*req); | Releases a request.|
| int32_t UsbFnFreeRequest(struct UsbFnRequest \*req); | Releases a request.|
| int32_t UsbFnSubmitRequestAsync(struct UsbFnRequest<br>\*req); | Sends an asynchronous request.|
| int32_t UsbFnSubmitRequestAsync(struct UsbFnRequest<br>\*req); | Sends an asynchronous request.|
| int32_t UsbFnSubmitRequestSync(struct UsbFnRequest<br>\*req, uint32_t timeout); | Sends a synchronous request.|
| int32_t UsbFnSubmitRequestSync(struct UsbFnRequest<br>\*req, uint32_t timeout); | Sends a synchronous request.|
| int32_t UsbFnCancelRequest(struct UsbFnRequest \*req); | Cancels a request.|
| int32_t UsbFnCancelRequest(struct UsbFnRequest \*req); | Cancels a request.|
