Lines Matching refs:HAL

41      * This must be a non-blocking call. The HAL should return from this call
52      *         The camera HAL does not support the input template type
69      * Reset the HAL camera device processing pipeline and set up new input and
82      * If the HAL needs to change the stream configuration for an existing
89      * If a currently-active stream is not included in streamList, the HAL may
95      * requestedConfiguration. Upon return, the HAL device must set producerUsage,
112      * release sync fences have been signaled by the HAL. The framework must not
118      * The HAL device must configure itself to provide maximum possible output
127      * Nevertheless, the HAL device should attempt to minimize the
132      * The HAL should return from this call in 500ms, and must return from this
153      *             the requested operation_mode is not supported by the HAL.
158      *         for a given camera device hardware level. The HAL must return an
162      * @return finalConfiguration The stream parameters desired by the HAL for
174      * Send a list of capture requests to the HAL. The HAL must not return from
182      * client, the HAL must process the requests in order of lowest index to
187      * by camera HAL. Camera HAL must remove these cache entries whether or not
191      * capture being returned by the HAL through the processCaptureResult()
197      * guaranteed to be valid during this call. The HAL device must make copies
198      * of the information it needs to retain for the capture processing. The HAL
202      * The HAL must write the file descriptor for the input buffer's release
204      * valid. If the HAL returns -1 for the input buffer release sync fence, the
210      * may be brand new (having never before seen by the HAL).
220      * quality settings set to FAST). The HAL should return this call in 1
232      *         stream buffers' fences and the buffer handles; the HAL must not
240      *     camera HAL. When status is OK, this must be equal to the size of
242      *     that HAL processed successfully before HAL runs into an error.
291      * returned with CAMERA3_BUFFER_STATUS_ERROR. Note the HAL is still allowed
295      * All requests currently in the HAL are expected to be returned as soon as
304      * that from the HAL's point of view, a processCaptureRequest() call may
306      * a call happens before flush() returns, the HAL must treat the new
309      * More specifically, the HAL must follow below requirements for various
312      * 1. For captures that are too late for the HAL to cancel/stop, and must be
313      *    completed normally by the HAL; i.e. the HAL can send shutter/notify
316      * 2. For pending requests that have not done any processing, the HAL must
319      *    (CAMERA3_BUFFER_STATUS_ERROR). The HAL must not place the release
322      *    waited on by the HAL already. This is also the path to follow for any
323      *    captures for which the HAL already called notify() with
331      *    output buffers or perhaps missing metadata, the HAL must follow
345      *    3.4. For captures that will produce some results, the HAL must not
371      * requests left in the HAL. The framework may call configure_streams (as
372      * the HAL state is now quiesced) or may issue new requests.
381      * The HAL should return from this call in 100ms, and must return from this
387      *         On a successful flush of the camera HAL.