# Interfaces
Source: [https://docs.qualcomm.com/doc/80-70015-7/topic/qsh_api_reference.html](https://docs.qualcomm.com/doc/80-70015-7/topic/qsh_api_reference.html)
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. The QSH client
APIs are for the applications and the QSH sensor APIs are for the development of new
sensors on a low-power processor.
## QSH client APIs at application processor
Source: [https://docs.qualcomm.com/doc/80-70015-7/topic/qsh_api_reference.html](https://docs.qualcomm.com/doc/80-70015-7/topic/qsh_api_reference.html)
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 and/or 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:
- User trying to send a request over a closed session
- Encoded message size exceeding the permissible size
- Sending message fails due to channel related issue
|
**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-70015-7/samples.html).
## Low-power processor APIs
Source: [https://docs.qualcomm.com/doc/80-70015-7/topic/qsh_api_reference.html](https://docs.qualcomm.com/doc/80-70015-7/topic/qsh_api_reference.html)
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-70015-7A/qsh_api_reference.html) in [Qualcomm Linux Sensors Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70015-7A/overview.html).
Note: [Qualcomm Linux Sensors Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70015-7A/overview.html) is
available to licensed users with authorized access.
Last Published: Oct 14, 2024
[Previous Topic
Architecture](https://docs.qualcomm.com/bundle/publicresource/80-70015-7/topics/architecture.md) [Next Topic
Software](https://docs.qualcomm.com/bundle/publicresource/80-70015-7/topics/software.md)