#include <cafe/hid.h> HID_ERROR_CODE HIDWrite( u32 handle, u8 *p_buffer, u32 buffer_length, HIDCallback async_callback, void *p_user );
|handle||Handle associated with the HID device.|
|p_buffer||Pointer to buffer to send transaction data. This buffer must be aligned and padded to
|buffer_length||Size of the buffer to receive transaction data in bytes.|
|p_user||User-specified pointer passed to
For blocking calls, a return value of ≥
0 specifies the number of bytes transferred for the request.
For asynchronous calls, a return value of
HID_ERROR_OK specifies that the call was initiated successfully and
the result of the transaction will be specified in the
HIDCallback parameters upon completion.
HID device driver should be prepared to handle device specific errors at run time. These are device dependent and cannot be defined here.
Typically a USB device stalls when transactions are not supported, please consult specifications for the specific device.
The driver should issue valid transactions to prevent these issues or be prepared to issue
HIDResetDevice on error and receive a new attach for the device on error.
HID is intended for human interface, very low frequency, thus there is typically no reason to issue multiple pending transactions.
HID devices such as keyboards and mice will buffer input for the next posted transaction thus transactions can be done in a loop by issuing the next transaction in the completion function.
These following errors may be encountered for other reasons.
HID_ERROR_ALLOC_IPC_BUFFERmay be returned if there is insufficient memory for IPC transaction. A finite amount of IPC buffers are available for HID to make transactions. This is not associated with device error.
UHS_STATUS_INVALID_HANDLEmay be returned when the device associated with the handle is no longer attached, or it has detach and re-attached using new handle. This is not associated with device error.
UHS_STATUS_TXN_CANCELLEDmay be returned when the device is detached or HID driver is closed after a pending transaction is issued. This is not associated with device error.
Typically, under normal operations, the driver should stop reading or writing on any error in the read or write loop. This is as observed with keyboards and mice, other devices may have specific reasons for error, device errors usually come form the device as a stall if the device follows USB specification.
|Background||Do not call this function from the background.|
2013/05/08 Automated cleanup pass.
2011/09/29 Initial version.