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      * set to 0. The usage must be set to the consumer usage flags. The HAL
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
154      *             supported by the HAL.
159      *         for a given camera device hardware level. The HAL must return an
163      * @return finalConfiguration The stream parameters desired by the HAL for
175      * Send a list of capture requests to the HAL. The HAL must not return from
183      * client, the HAL must process the requests in order of lowest index to
188      * by camera HAL. Camera HAL must remove these cache entries whether or not
192      * capture being returned by the HAL through the processCaptureResult()
198      * guaranteed to be valid during this call. The HAL device must make copies
199      * of the information it needs to retain for the capture processing. The HAL
203      * The HAL must write the file descriptor for the input buffer's release
205      * valid. If the HAL returns -1 for the input buffer release sync fence, the
211      * may be brand new (having never before seen by the HAL).
221      * quality settings set to FAST). The HAL should return this call in 1
233      *         stream buffers' fences and the buffer handles; the HAL must not
241      *     camera HAL. When status is OK, this must be equal to the size of
243      *     that HAL processed successfully before HAL runs into an error.
292      * returned with CAMERA3_BUFFER_STATUS_ERROR. Note the HAL is still allowed
296      * All requests currently in the HAL are expected to be returned as soon as
305      * that from the HAL's point of view, a processCaptureRequest() call may
307      * a call happens before flush() returns, the HAL must treat the new
310      * More specifically, the HAL must follow below requirements for various
313      * 1. For captures that are too late for the HAL to cancel/stop, and must be
314      *    completed normally by the HAL; i.e. the HAL can send shutter/notify
317      * 2. For pending requests that have not done any processing, the HAL must
320      *    (CAMERA3_BUFFER_STATUS_ERROR). The HAL must not place the release
323      *    waited on by the HAL already. This is also the path to follow for any
324      *    captures for which the HAL already called notify() with
332      *    output buffers or perhaps missing metadata, the HAL must follow
346      *    3.4. For captures that will produce some results, the HAL must not
372      * requests left in the HAL. The framework may call configure_streams (as
373      * the HAL state is now quiesced) or may issue new requests.
382      * The HAL should return from this call in 100ms, and must return from this
388      *         On a successful flush of the camera HAL.