# Interfaces Certain QSH interfaces described here contain the important QSH functions, classes, methods, and data structures. These QSH interfaces are available for working with any kind of hardware-based, software-based, pre-existing, or any other QSH-compliant sensors. The QSH framework runs on the low-power processors and exposes APIs at application processor, which includes the following: - QSH client APIs and various feature APIs for application development - Sensor APIs for creating new sensors on a low-power processor. ## Application processor APIs QSH offers various feature APIs at the application processor, designed to meet specific needs of different use cases. ### QSH client APIs The QSH client APIs provide a simple and easy interface to the client code that enables the QSH functionality and develops an end-to-end sensor use case. The QSH supports the following APIs: **getSession()** This API creates an instance of `ISession` and returns a pointer to it. **Syntax** ISession* getSession(); Copy to clipboard **Parameters** None. **Response** | **Return** | **Description** | | --- | --- | | `ISession*` | `ISession`: Upon success


`nullptr`: Upon failure | **Open()** This API initiates the client session created using `getSession()`. It sets up and establishes communication between the client and the QSH framework. The client must call this function only once per session. **Syntax** int open(); Copy to clipboard **Parameters** None. **Response** | **Return** | **Description** | | --- | --- | | `int` | `0`: Successfully opened session


`-1`: Upon failure | **setCallBacks()** For a given SUID, this API allows the user to set callbacks for responses, errors, and events received over the session opened using `open()`. This API registers the SUID with the callback functions passed as parameters to this API. To unset the callbacks for already registered SUID, the user might pass `nullptr` for all the three callback functions - `respCallBack`, `errorCallBack`, and `eventCallBack`. For any unregistered SUID, passing `nullptr` for all callback functions is considered as an error. **Syntax** virtual int setCallBacks(suid suid, respCallBack respCB, errorCallBack errorCB, eventCallBack eventCB) = 0; Copy to clipboard **Parameters** | **Parameter** | **Name** | **Description** | | --- | --- | --- | | `input` | `suid` | Unique SUID of the sensor for which the callbacks are to be set. | | `input` | `respCB` | Response callback function. | | `input` | `errorCB` | Error callback function. | | `input` | `eventCB` | Event callback function. | Note If any callback function is not defined or required, then the client can pass `nullptr`. **Response** | **Return** | **Description** | | --- | --- | | `int` | `0`: Upon success


`-1`: Upon failure — if all the callback functions are `nullptr`, for an unregistered SUID. | **sendRequest()** This API asynchronously sends a protocol buffer (proto) encoded message to the QSH framework. The proto-encoded message contains instructions or configuration settings for the sensor identified by the SUID. If the user sets callback pointers using `setCallBacks()` for the given SUID, then the response, event, or a combination of responses and events are received from the QSH framework. **Syntax** virtual int sendRequest(suid suid, string message) = 0; Copy to clipboard **Parameters** | **Parameter** | **Name** | **Description** | | --- | --- | --- | | `input` | `suid` | A unique SUID of the sensor for request is to be sent. | | `input` | `message` | Proto-encoded request message to be sent. | **Response** | **Return** | **Description** | | --- | --- | | `int` | `0`: Upon success


`-1`: Upon failure, due to:
| **Close()** This API closes the sensor session, and terminates the communication between the client and the QSH framework. The client must call this function at the end of the session to release the resources and avoid memory leaks. **Syntax** void close(); Copy to clipboard **Parameters** None. **Response** | **Return** | **Description** | | --- | --- | | `void` | None | For more information and example codes, see [Samples](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-7/samples.html). ### QSH direct channel APIs QSH direct channel APIs provide low latency sensor data channel for high rate applications. Direct channel APIs use the fastRPC interface, which bypasses the standard interprocessor communication (IPC) mechanism to achieve faster communication. For more information, see [Interfaces](https://docs.qualcomm.com/bundle/resource/topics/80-70017-7A/qsh_api_reference.html) in [Qualcomm Linux Sensors Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70017-7A/overview.html). Note [Qualcomm Linux Sensors Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70017-7A/overview.html) is available to licensed users with authorized access. ## Low-power processor APIs The low-power processor APIs provide access to: - QSH framework resources, such as services and utilities - Core functionalities, such as the diagnostic interface and timer You can use the low-power processor APIs to create algorithms and sensor drivers that comply with the QSH standards. This information is available to the licensed users who have full access to the proprietary software shipped with Qualcomm Linux. For more information, see [Interfaces](https://docs.qualcomm.com/bundle/resource/topics/80-70017-7A/qsh_api_reference.html) in [Qualcomm Linux Sensors Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70017-7A/overview.html). Note [Qualcomm Linux Sensors Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70017-7A/overview.html) is available to licensed users with authorized access. Last Published: Dec 24, 2024 [Previous Topic Architecture](https://docs.qualcomm.com/bundle/publicresource/80-70017-7/topics/architecture.md) [Next Topic Software](https://docs.qualcomm.com/bundle/publicresource/80-70017-7/topics/software.md)