GoogleGit

blob: b70510317815e707525cd2da4da6c5730da93ef5 [file] [log] [blame]
  1. /*
  2. * Copyright (C) 2013 The Android Open Source Project
  3. *
  4. * Licensed under the Apache License, Version 2.0 (the "License");
  5. * you may not use this file except in compliance with the License.
  6. * You may obtain a copy of the License at
  7. *
  8. * http://www.apache.org/licenses/LICENSE-2.0
  9. *
  10. * Unless required by applicable law or agreed to in writing, software
  11. * distributed under the License is distributed on an "AS IS" BASIS,
  12. * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  13. * See the License for the specific language governing permissions and
  14. * limitations under the License.
  15. */
  16. #ifndef ANDROID_INCLUDE_CAMERA3_H
  17. #define ANDROID_INCLUDE_CAMERA3_H
  18. #include <system/camera_metadata.h>
  19. #include "camera_common.h"
  20. /**
  21. * Camera device HAL 3.2 [ CAMERA_DEVICE_API_VERSION_3_2 ]
  22. *
  23. * This is the current recommended version of the camera device HAL.
  24. *
  25. * Supports the android.hardware.Camera API, and as of v3.2, the
  26. * android.hardware.camera2 API in LIMITED or FULL modes.
  27. *
  28. * Camera devices that support this version of the HAL must return
  29. * CAMERA_DEVICE_API_VERSION_3_2 in camera_device_t.common.version and in
  30. * camera_info_t.device_version (from camera_module_t.get_camera_info).
  31. *
  32. * CAMERA_DEVICE_API_VERSION_3_2:
  33. * Camera modules that may contain version 3.2 devices must implement at
  34. * least version 2.2 of the camera module interface (as defined by
  35. * camera_module_t.common.module_api_version).
  36. *
  37. * <= CAMERA_DEVICE_API_VERSION_3_1:
  38. * Camera modules that may contain version 3.1 (or 3.0) devices must
  39. * implement at least version 2.0 of the camera module interface
  40. * (as defined by camera_module_t.common.module_api_version).
  41. *
  42. * See camera_common.h for more versioning details.
  43. *
  44. * Documentation index:
  45. * S1. Version history
  46. * S2. Startup and operation sequencing
  47. * S3. Operational modes
  48. * S4. 3A modes and state machines
  49. * S5. Cropping
  50. * S6. Error management
  51. * S7. Key Performance Indicator (KPI) glossary
  52. * S8. Sample Use Cases
  53. * S9. Notes on Controls and Metadata
  54. */
  55. /**
  56. * S1. Version history:
  57. *
  58. * 1.0: Initial Android camera HAL (Android 4.0) [camera.h]:
  59. *
  60. * - Converted from C++ CameraHardwareInterface abstraction layer.
  61. *
  62. * - Supports android.hardware.Camera API.
  63. *
  64. * 2.0: Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:
  65. *
  66. * - Sufficient for implementing existing android.hardware.Camera API.
  67. *
  68. * - Allows for ZSL queue in camera service layer
  69. *
  70. * - Not tested for any new features such manual capture control, Bayer RAW
  71. * capture, reprocessing of RAW data.
  72. *
  73. * 3.0: First revision of expanded-capability HAL:
  74. *
  75. * - Major version change since the ABI is completely different. No change to
  76. * the required hardware capabilities or operational model from 2.0.
  77. *
  78. * - Reworked input request and stream queue interfaces: Framework calls into
  79. * HAL with next request and stream buffers already dequeued. Sync framework
  80. * support is included, necessary for efficient implementations.
  81. *
  82. * - Moved triggers into requests, most notifications into results.
  83. *
  84. * - Consolidated all callbacks into framework into one structure, and all
  85. * setup methods into a single initialize() call.
  86. *
  87. * - Made stream configuration into a single call to simplify stream
  88. * management. Bidirectional streams replace STREAM_FROM_STREAM construct.
  89. *
  90. * - Limited mode semantics for older/limited hardware devices.
  91. *
  92. * 3.1: Minor revision of expanded-capability HAL:
  93. *
  94. * - configure_streams passes consumer usage flags to the HAL.
  95. *
  96. * - flush call to drop all in-flight requests/buffers as fast as possible.
  97. *
  98. * 3.2: Minor revision of expanded-capability HAL:
  99. *
  100. * - Deprecates get_metadata_vendor_tag_ops. Please use get_vendor_tag_ops
  101. * in camera_common.h instead.
  102. *
  103. * - register_stream_buffers deprecated. All gralloc buffers provided
  104. * by framework to HAL in process_capture_request may be new at any time.
  105. *
  106. * - add partial result support. process_capture_result may be called
  107. * multiple times with a subset of the available result before the full
  108. * result is available.
  109. *
  110. * - add manual template to camera3_request_template. The applications may
  111. * use this template to control the capture settings directly.
  112. *
  113. * - Rework the bidirectional and input stream specifications.
  114. *
  115. * - change the input buffer return path. The buffer is returned in
  116. * process_capture_result instead of process_capture_request.
  117. *
  118. */
  119. /**
  120. * S2. Startup and general expected operation sequence:
  121. *
  122. * 1. Framework calls camera_module_t->common.open(), which returns a
  123. * hardware_device_t structure.
  124. *
  125. * 2. Framework inspects the hardware_device_t->version field, and instantiates
  126. * the appropriate handler for that version of the camera hardware device. In
  127. * case the version is CAMERA_DEVICE_API_VERSION_3_0, the device is cast to
  128. * a camera3_device_t.
  129. *
  130. * 3. Framework calls camera3_device_t->ops->initialize() with the framework
  131. * callback function pointers. This will only be called this one time after
  132. * open(), before any other functions in the ops structure are called.
  133. *
  134. * 4. The framework calls camera3_device_t->ops->configure_streams() with a list
  135. * of input/output streams to the HAL device.
  136. *
  137. * 5. <= CAMERA_DEVICE_API_VERSION_3_1:
  138. *
  139. * The framework allocates gralloc buffers and calls
  140. * camera3_device_t->ops->register_stream_buffers() for at least one of the
  141. * output streams listed in configure_streams. The same stream is registered
  142. * only once.
  143. *
  144. * >= CAMERA_DEVICE_API_VERSION_3_2:
  145. *
  146. * camera3_device_t->ops->register_stream_buffers() is not called and must
  147. * be NULL.
  148. *
  149. * 6. The framework requests default settings for some number of use cases with
  150. * calls to camera3_device_t->ops->construct_default_request_settings(). This
  151. * may occur any time after step 3.
  152. *
  153. * 7. The framework constructs and sends the first capture request to the HAL,
  154. * with settings based on one of the sets of default settings, and with at
  155. * least one output stream, which has been registered earlier by the
  156. * framework. This is sent to the HAL with
  157. * camera3_device_t->ops->process_capture_request(). The HAL must block the
  158. * return of this call until it is ready for the next request to be sent.
  159. *
  160. * >= CAMERA_DEVICE_API_VERSION_3_2:
  161. *
  162. * The buffer_handle_t provided in the camera3_stream_buffer_t array
  163. * in the camera3_capture_request_t may be new and never-before-seen
  164. * by the HAL on any given new request.
  165. *
  166. * 8. The framework continues to submit requests, and call
  167. * construct_default_request_settings to get default settings buffers for
  168. * other use cases.
  169. *
  170. * <= CAMERA_DEVICE_API_VERSION_3_1:
  171. *
  172. * The framework may call register_stream_buffers() at this time for
  173. * not-yet-registered streams.
  174. *
  175. * 9. When the capture of a request begins (sensor starts exposing for the
  176. * capture), the HAL calls camera3_callback_ops_t->notify() with the SHUTTER
  177. * event, including the frame number and the timestamp for start of exposure.
  178. *
  179. * <= CAMERA_DEVICE_API_VERSION_3_1:
  180. *
  181. * This notify call must be made before the first call to
  182. * process_capture_result() for that frame number.
  183. *
  184. * >= CAMERA_DEVICE_API_VERSION_3_2:
  185. *
  186. * The camera3_callback_ops_t->notify() call with the SHUTTER event should
  187. * be made as early as possible since the framework will be unable to
  188. * deliver gralloc buffers to the application layer (for that frame) until
  189. * it has a valid timestamp for the start of exposure.
  190. *
  191. * Both partial metadata results and the gralloc buffers may be sent to the
  192. * framework at any time before or after the SHUTTER event.
  193. *
  194. * 10. After some pipeline delay, the HAL begins to return completed captures to
  195. * the framework with camera3_callback_ops_t->process_capture_result(). These
  196. * are returned in the same order as the requests were submitted. Multiple
  197. * requests can be in flight at once, depending on the pipeline depth of the
  198. * camera HAL device.
  199. *
  200. * >= CAMERA_DEVICE_API_VERSION_3_2:
  201. *
  202. * Once a buffer is returned by process_capture_result as part of the
  203. * camera3_stream_buffer_t array, and the fence specified by release_fence
  204. * has been signaled (this is a no-op for -1 fences), the ownership of that
  205. * buffer is considered to be transferred back to the framework. After that,
  206. * the HAL must no longer retain that particular buffer, and the
  207. * framework may clean up the memory for it immediately.
  208. *
  209. * process_capture_result may be called multiple times for a single frame,
  210. * each time with a new disjoint piece of metadata and/or set of gralloc
  211. * buffers. The framework will accumulate these partial metadata results
  212. * into one result.
  213. *
  214. * In particular, it is legal for a process_capture_result to be called
  215. * simultaneously for both a frame N and a frame N+1 as long as the
  216. * above rule holds for gralloc buffers (both input and output).
  217. *
  218. * 11. After some time, the framework may stop submitting new requests, wait for
  219. * the existing captures to complete (all buffers filled, all results
  220. * returned), and then call configure_streams() again. This resets the camera
  221. * hardware and pipeline for a new set of input/output streams. Some streams
  222. * may be reused from the previous configuration; if these streams' buffers
  223. * had already been registered with the HAL, they will not be registered
  224. * again. The framework then continues from step 7, if at least one
  225. * registered output stream remains (otherwise, step 5 is required first).
  226. *
  227. * 12. Alternatively, the framework may call camera3_device_t->common->close()
  228. * to end the camera session. This may be called at any time when no other
  229. * calls from the framework are active, although the call may block until all
  230. * in-flight captures have completed (all results returned, all buffers
  231. * filled). After the close call returns, no more calls to the
  232. * camera3_callback_ops_t functions are allowed from the HAL. Once the
  233. * close() call is underway, the framework may not call any other HAL device
  234. * functions.
  235. *
  236. * 13. In case of an error or other asynchronous event, the HAL must call
  237. * camera3_callback_ops_t->notify() with the appropriate error/event
  238. * message. After returning from a fatal device-wide error notification, the
  239. * HAL should act as if close() had been called on it. However, the HAL must
  240. * either cancel or complete all outstanding captures before calling
  241. * notify(), so that once notify() is called with a fatal error, the
  242. * framework will not receive further callbacks from the device. Methods
  243. * besides close() should return -ENODEV or NULL after the notify() method
  244. * returns from a fatal error message.
  245. */
  246. /**
  247. * S3. Operational modes:
  248. *
  249. * The camera 3 HAL device can implement one of two possible operational modes;
  250. * limited and full. Full support is expected from new higher-end
  251. * devices. Limited mode has hardware requirements roughly in line with those
  252. * for a camera HAL device v1 implementation, and is expected from older or
  253. * inexpensive devices. Full is a strict superset of limited, and they share the
  254. * same essential operational flow, as documented above.
  255. *
  256. * The HAL must indicate its level of support with the
  257. * android.info.supportedHardwareLevel static metadata entry, with 0 indicating
  258. * limited mode, and 1 indicating full mode support.
  259. *
  260. * Roughly speaking, limited-mode devices do not allow for application control
  261. * of capture settings (3A control only), high-rate capture of high-resolution
  262. * images, raw sensor readout, or support for YUV output streams above maximum
  263. * recording resolution (JPEG only for large images).
  264. *
  265. * ** Details of limited mode behavior:
  266. *
  267. * - Limited-mode devices do not need to implement accurate synchronization
  268. * between capture request settings and the actual image data
  269. * captured. Instead, changes to settings may take effect some time in the
  270. * future, and possibly not for the same output frame for each settings
  271. * entry. Rapid changes in settings may result in some settings never being
  272. * used for a capture. However, captures that include high-resolution output
  273. * buffers ( > 1080p ) have to use the settings as specified (but see below
  274. * for processing rate).
  275. *
  276. * - Limited-mode devices do not need to support most of the
  277. * settings/result/static info metadata. Specifically, only the following settings
  278. * are expected to be consumed or produced by a limited-mode HAL device:
  279. *
  280. * android.control.aeAntibandingMode (controls and dynamic)
  281. * android.control.aeExposureCompensation (controls and dynamic)
  282. * android.control.aeLock (controls and dynamic)
  283. * android.control.aeMode (controls and dynamic)
  284. * android.control.aeRegions (controls and dynamic)
  285. * android.control.aeTargetFpsRange (controls and dynamic)
  286. * android.control.aePrecaptureTrigger (controls and dynamic)
  287. * android.control.afMode (controls and dynamic)
  288. * android.control.afRegions (controls and dynamic)
  289. * android.control.awbLock (controls and dynamic)
  290. * android.control.awbMode (controls and dynamic)
  291. * android.control.awbRegions (controls and dynamic)
  292. * android.control.captureIntent (controls and dynamic)
  293. * android.control.effectMode (controls and dynamic)
  294. * android.control.mode (controls and dynamic)
  295. * android.control.sceneMode (controls and dynamic)
  296. * android.control.videoStabilizationMode (controls and dynamic)
  297. * android.control.aeAvailableAntibandingModes (static)
  298. * android.control.aeAvailableModes (static)
  299. * android.control.aeAvailableTargetFpsRanges (static)
  300. * android.control.aeCompensationRange (static)
  301. * android.control.aeCompensationStep (static)
  302. * android.control.afAvailableModes (static)
  303. * android.control.availableEffects (static)
  304. * android.control.availableSceneModes (static)
  305. * android.control.availableVideoStabilizationModes (static)
  306. * android.control.awbAvailableModes (static)
  307. * android.control.maxRegions (static)
  308. * android.control.sceneModeOverrides (static)
  309. * android.control.aeState (dynamic)
  310. * android.control.afState (dynamic)
  311. * android.control.awbState (dynamic)
  312. *
  313. * android.flash.mode (controls and dynamic)
  314. * android.flash.info.available (static)
  315. *
  316. * android.info.supportedHardwareLevel (static)
  317. *
  318. * android.jpeg.gpsCoordinates (controls and dynamic)
  319. * android.jpeg.gpsProcessingMethod (controls and dynamic)
  320. * android.jpeg.gpsTimestamp (controls and dynamic)
  321. * android.jpeg.orientation (controls and dynamic)
  322. * android.jpeg.quality (controls and dynamic)
  323. * android.jpeg.thumbnailQuality (controls and dynamic)
  324. * android.jpeg.thumbnailSize (controls and dynamic)
  325. * android.jpeg.availableThumbnailSizes (static)
  326. * android.jpeg.maxSize (static)
  327. *
  328. * android.lens.info.minimumFocusDistance (static)
  329. *
  330. * android.request.id (controls and dynamic)
  331. *
  332. * android.scaler.cropRegion (controls and dynamic)
  333. * android.scaler.availableStreamConfigurations (static)
  334. * android.scaler.availableMinFrameDurations (static)
  335. * android.scaler.availableStallDurations (static)
  336. * android.scaler.availableMaxDigitalZoom (static)
  337. * android.scaler.maxDigitalZoom (static)
  338. * android.scaler.croppingType (static)
  339. *
  340. * android.sensor.orientation (static)
  341. * android.sensor.timestamp (dynamic)
  342. *
  343. * android.statistics.faceDetectMode (controls and dynamic)
  344. * android.statistics.info.availableFaceDetectModes (static)
  345. * android.statistics.faceIds (dynamic)
  346. * android.statistics.faceLandmarks (dynamic)
  347. * android.statistics.faceRectangles (dynamic)
  348. * android.statistics.faceScores (dynamic)
  349. *
  350. * android.sync.frameNumber (dynamic)
  351. * android.sync.maxLatency (static)
  352. *
  353. * - Captures in limited mode that include high-resolution (> 1080p) output
  354. * buffers may block in process_capture_request() until all the output buffers
  355. * have been filled. A full-mode HAL device must process sequences of
  356. * high-resolution requests at the rate indicated in the static metadata for
  357. * that pixel format. The HAL must still call process_capture_result() to
  358. * provide the output; the framework must simply be prepared for
  359. * process_capture_request() to block until after process_capture_result() for
  360. * that request completes for high-resolution captures for limited-mode
  361. * devices.
  362. *
  363. * - Full-mode devices must support below additional capabilities:
  364. * - 30fps at maximum resolution is preferred, more than 20fps is required.
  365. * - Per frame control (android.sync.maxLatency == PER_FRAME_CONTROL).
  366. * - Sensor manual control metadata. See MANUAL_SENSOR defined in
  367. * android.request.availableCapabilities.
  368. * - Post-processing manual control metadata. See MANUAL_POST_PROCESSING defined
  369. * in android.request.availableCapabilities.
  370. *
  371. */
  372. /**
  373. * S4. 3A modes and state machines:
  374. *
  375. * While the actual 3A algorithms are up to the HAL implementation, a high-level
  376. * state machine description is defined by the HAL interface, to allow the HAL
  377. * device and the framework to communicate about the current state of 3A, and to
  378. * trigger 3A events.
  379. *
  380. * When the device is opened, all the individual 3A states must be
  381. * STATE_INACTIVE. Stream configuration does not reset 3A. For example, locked
  382. * focus must be maintained across the configure() call.
  383. *
  384. * Triggering a 3A action involves simply setting the relevant trigger entry in
  385. * the settings for the next request to indicate start of trigger. For example,
  386. * the trigger for starting an autofocus scan is setting the entry
  387. * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTROL_AF_TRIGGER_START for one
  388. * request, and cancelling an autofocus scan is triggered by setting
  389. * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTRL_AF_TRIGGER_CANCEL. Otherwise,
  390. * the entry will not exist, or be set to ANDROID_CONTROL_AF_TRIGGER_IDLE. Each
  391. * request with a trigger entry set to a non-IDLE value will be treated as an
  392. * independent triggering event.
  393. *
  394. * At the top level, 3A is controlled by the ANDROID_CONTROL_MODE setting, which
  395. * selects between no 3A (ANDROID_CONTROL_MODE_OFF), normal AUTO mode
  396. * (ANDROID_CONTROL_MODE_AUTO), and using the scene mode setting
  397. * (ANDROID_CONTROL_USE_SCENE_MODE).
  398. *
  399. * - In OFF mode, each of the individual AE/AF/AWB modes are effectively OFF,
  400. * and none of the capture controls may be overridden by the 3A routines.
  401. *
  402. * - In AUTO mode, Auto-focus, auto-exposure, and auto-whitebalance all run
  403. * their own independent algorithms, and have their own mode, state, and
  404. * trigger metadata entries, as listed in the next section.
  405. *
  406. * - In USE_SCENE_MODE, the value of the ANDROID_CONTROL_SCENE_MODE entry must
  407. * be used to determine the behavior of 3A routines. In SCENE_MODEs other than
  408. * FACE_PRIORITY, the HAL must override the values of
  409. * ANDROId_CONTROL_AE/AWB/AF_MODE to be the mode it prefers for the selected
  410. * SCENE_MODE. For example, the HAL may prefer SCENE_MODE_NIGHT to use
  411. * CONTINUOUS_FOCUS AF mode. Any user selection of AE/AWB/AF_MODE when scene
  412. * must be ignored for these scene modes.
  413. *
  414. * - For SCENE_MODE_FACE_PRIORITY, the AE/AWB/AF_MODE controls work as in
  415. * ANDROID_CONTROL_MODE_AUTO, but the 3A routines must bias toward metering
  416. * and focusing on any detected faces in the scene.
  417. *
  418. * S4.1. Auto-focus settings and result entries:
  419. *
  420. * Main metadata entries:
  421. *
  422. * ANDROID_CONTROL_AF_MODE: Control for selecting the current autofocus
  423. * mode. Set by the framework in the request settings.
  424. *
  425. * AF_MODE_OFF: AF is disabled; the framework/app directly controls lens
  426. * position.
  427. *
  428. * AF_MODE_AUTO: Single-sweep autofocus. No lens movement unless AF is
  429. * triggered.
  430. *
  431. * AF_MODE_MACRO: Single-sweep up-close autofocus. No lens movement unless
  432. * AF is triggered.
  433. *
  434. * AF_MODE_CONTINUOUS_VIDEO: Smooth continuous focusing, for recording
  435. * video. Triggering immediately locks focus in current
  436. * position. Canceling resumes cotinuous focusing.
  437. *
  438. * AF_MODE_CONTINUOUS_PICTURE: Fast continuous focusing, for
  439. * zero-shutter-lag still capture. Triggering locks focus once currently
  440. * active sweep concludes. Canceling resumes continuous focusing.
  441. *
  442. * AF_MODE_EDOF: Advanced extended depth of field focusing. There is no
  443. * autofocus scan, so triggering one or canceling one has no effect.
  444. * Images are focused automatically by the HAL.
  445. *
  446. * ANDROID_CONTROL_AF_STATE: Dynamic metadata describing the current AF
  447. * algorithm state, reported by the HAL in the result metadata.
  448. *
  449. * AF_STATE_INACTIVE: No focusing has been done, or algorithm was
  450. * reset. Lens is not moving. Always the state for MODE_OFF or MODE_EDOF.
  451. * When the device is opened, it must start in this state.
  452. *
  453. * AF_STATE_PASSIVE_SCAN: A continuous focus algorithm is currently scanning
  454. * for good focus. The lens is moving.
  455. *
  456. * AF_STATE_PASSIVE_FOCUSED: A continuous focus algorithm believes it is
  457. * well focused. The lens is not moving. The HAL may spontaneously leave
  458. * this state.
  459. *
  460. * AF_STATE_PASSIVE_UNFOCUSED: A continuous focus algorithm believes it is
  461. * not well focused. The lens is not moving. The HAL may spontaneously
  462. * leave this state.
  463. *
  464. * AF_STATE_ACTIVE_SCAN: A scan triggered by the user is underway.
  465. *
  466. * AF_STATE_FOCUSED_LOCKED: The AF algorithm believes it is focused. The
  467. * lens is not moving.
  468. *
  469. * AF_STATE_NOT_FOCUSED_LOCKED: The AF algorithm has been unable to
  470. * focus. The lens is not moving.
  471. *
  472. * ANDROID_CONTROL_AF_TRIGGER: Control for starting an autofocus scan, the
  473. * meaning of which is mode- and state- dependent. Set by the framework in
  474. * the request settings.
  475. *
  476. * AF_TRIGGER_IDLE: No current trigger.
  477. *
  478. * AF_TRIGGER_START: Trigger start of AF scan. Effect is mode and state
  479. * dependent.
  480. *
  481. * AF_TRIGGER_CANCEL: Cancel current AF scan if any, and reset algorithm to
  482. * default.
  483. *
  484. * Additional metadata entries:
  485. *
  486. * ANDROID_CONTROL_AF_REGIONS: Control for selecting the regions of the FOV
  487. * that should be used to determine good focus. This applies to all AF
  488. * modes that scan for focus. Set by the framework in the request
  489. * settings.
  490. *
  491. * S4.2. Auto-exposure settings and result entries:
  492. *
  493. * Main metadata entries:
  494. *
  495. * ANDROID_CONTROL_AE_MODE: Control for selecting the current auto-exposure
  496. * mode. Set by the framework in the request settings.
  497. *
  498. * AE_MODE_OFF: Autoexposure is disabled; the user controls exposure, gain,
  499. * frame duration, and flash.
  500. *
  501. * AE_MODE_ON: Standard autoexposure, with flash control disabled. User may
  502. * set flash to fire or to torch mode.
  503. *
  504. * AE_MODE_ON_AUTO_FLASH: Standard autoexposure, with flash on at HAL's
  505. * discretion for precapture and still capture. User control of flash
  506. * disabled.
  507. *
  508. * AE_MODE_ON_ALWAYS_FLASH: Standard autoexposure, with flash always fired
  509. * for capture, and at HAL's discretion for precapture.. User control of
  510. * flash disabled.
  511. *
  512. * AE_MODE_ON_AUTO_FLASH_REDEYE: Standard autoexposure, with flash on at
  513. * HAL's discretion for precapture and still capture. Use a flash burst
  514. * at end of precapture sequence to reduce redeye in the final
  515. * picture. User control of flash disabled.
  516. *
  517. * ANDROID_CONTROL_AE_STATE: Dynamic metadata describing the current AE
  518. * algorithm state, reported by the HAL in the result metadata.
  519. *
  520. * AE_STATE_INACTIVE: Initial AE state after mode switch. When the device is
  521. * opened, it must start in this state.
  522. *
  523. * AE_STATE_SEARCHING: AE is not converged to a good value, and is adjusting
  524. * exposure parameters.
  525. *
  526. * AE_STATE_CONVERGED: AE has found good exposure values for the current
  527. * scene, and the exposure parameters are not changing. HAL may
  528. * spontaneously leave this state to search for better solution.
  529. *
  530. * AE_STATE_LOCKED: AE has been locked with the AE_LOCK control. Exposure
  531. * values are not changing.
  532. *
  533. * AE_STATE_FLASH_REQUIRED: The HAL has converged exposure, but believes
  534. * flash is required for a sufficiently bright picture. Used for
  535. * determining if a zero-shutter-lag frame can be used.
  536. *
  537. * AE_STATE_PRECAPTURE: The HAL is in the middle of a precapture
  538. * sequence. Depending on AE mode, this mode may involve firing the
  539. * flash for metering, or a burst of flash pulses for redeye reduction.
  540. *
  541. * ANDROID_CONTROL_AE_PRECAPTURE_TRIGGER: Control for starting a metering
  542. * sequence before capturing a high-quality image. Set by the framework in
  543. * the request settings.
  544. *
  545. * PRECAPTURE_TRIGGER_IDLE: No current trigger.
  546. *
  547. * PRECAPTURE_TRIGGER_START: Start a precapture sequence. The HAL should
  548. * use the subsequent requests to measure good exposure/white balance
  549. * for an upcoming high-resolution capture.
  550. *
  551. * Additional metadata entries:
  552. *
  553. * ANDROID_CONTROL_AE_LOCK: Control for locking AE controls to their current
  554. * values
  555. *
  556. * ANDROID_CONTROL_AE_EXPOSURE_COMPENSATION: Control for adjusting AE
  557. * algorithm target brightness point.
  558. *
  559. * ANDROID_CONTROL_AE_TARGET_FPS_RANGE: Control for selecting the target frame
  560. * rate range for the AE algorithm. The AE routine cannot change the frame
  561. * rate to be outside these bounds.
  562. *
  563. * ANDROID_CONTROL_AE_REGIONS: Control for selecting the regions of the FOV
  564. * that should be used to determine good exposure levels. This applies to
  565. * all AE modes besides OFF.
  566. *
  567. * S4.3. Auto-whitebalance settings and result entries:
  568. *
  569. * Main metadata entries:
  570. *
  571. * ANDROID_CONTROL_AWB_MODE: Control for selecting the current white-balance
  572. * mode.
  573. *
  574. * AWB_MODE_OFF: Auto-whitebalance is disabled. User controls color matrix.
  575. *
  576. * AWB_MODE_AUTO: Automatic white balance is enabled; 3A controls color
  577. * transform, possibly using more complex transforms than a simple
  578. * matrix.
  579. *
  580. * AWB_MODE_INCANDESCENT: Fixed white balance settings good for indoor
  581. * incandescent (tungsten) lighting, roughly 2700K.
  582. *
  583. * AWB_MODE_FLUORESCENT: Fixed white balance settings good for fluorescent
  584. * lighting, roughly 5000K.
  585. *
  586. * AWB_MODE_WARM_FLUORESCENT: Fixed white balance settings good for
  587. * fluorescent lighting, roughly 3000K.
  588. *
  589. * AWB_MODE_DAYLIGHT: Fixed white balance settings good for daylight,
  590. * roughly 5500K.
  591. *
  592. * AWB_MODE_CLOUDY_DAYLIGHT: Fixed white balance settings good for clouded
  593. * daylight, roughly 6500K.
  594. *
  595. * AWB_MODE_TWILIGHT: Fixed white balance settings good for
  596. * near-sunset/sunrise, roughly 15000K.
  597. *
  598. * AWB_MODE_SHADE: Fixed white balance settings good for areas indirectly
  599. * lit by the sun, roughly 7500K.
  600. *
  601. * ANDROID_CONTROL_AWB_STATE: Dynamic metadata describing the current AWB
  602. * algorithm state, reported by the HAL in the result metadata.
  603. *
  604. * AWB_STATE_INACTIVE: Initial AWB state after mode switch. When the device
  605. * is opened, it must start in this state.
  606. *
  607. * AWB_STATE_SEARCHING: AWB is not converged to a good value, and is
  608. * changing color adjustment parameters.
  609. *
  610. * AWB_STATE_CONVERGED: AWB has found good color adjustment values for the
  611. * current scene, and the parameters are not changing. HAL may
  612. * spontaneously leave this state to search for better solution.
  613. *
  614. * AWB_STATE_LOCKED: AWB has been locked with the AWB_LOCK control. Color
  615. * adjustment values are not changing.
  616. *
  617. * Additional metadata entries:
  618. *
  619. * ANDROID_CONTROL_AWB_LOCK: Control for locking AWB color adjustments to
  620. * their current values.
  621. *
  622. * ANDROID_CONTROL_AWB_REGIONS: Control for selecting the regions of the FOV
  623. * that should be used to determine good color balance. This applies only
  624. * to auto-WB mode.
  625. *
  626. * S4.4. General state machine transition notes
  627. *
  628. * Switching between AF, AE, or AWB modes always resets the algorithm's state
  629. * to INACTIVE. Similarly, switching between CONTROL_MODE or
  630. * CONTROL_SCENE_MODE if CONTROL_MODE == USE_SCENE_MODE resets all the
  631. * algorithm states to INACTIVE.
  632. *
  633. * The tables below are per-mode.
  634. *
  635. * S4.5. AF state machines
  636. *
  637. * when enabling AF or changing AF mode
  638. *| state | trans. cause | new state | notes |
  639. *+--------------------+---------------+--------------------+------------------+
  640. *| Any | AF mode change| INACTIVE | |
  641. *+--------------------+---------------+--------------------+------------------+
  642. *
  643. * mode = AF_MODE_OFF or AF_MODE_EDOF
  644. *| state | trans. cause | new state | notes |
  645. *+--------------------+---------------+--------------------+------------------+
  646. *| INACTIVE | | INACTIVE | Never changes |
  647. *+--------------------+---------------+--------------------+------------------+
  648. *
  649. * mode = AF_MODE_AUTO or AF_MODE_MACRO
  650. *| state | trans. cause | new state | notes |
  651. *+--------------------+---------------+--------------------+------------------+
  652. *| INACTIVE | AF_TRIGGER | ACTIVE_SCAN | Start AF sweep |
  653. *| | | | Lens now moving |
  654. *+--------------------+---------------+--------------------+------------------+
  655. *| ACTIVE_SCAN | AF sweep done | FOCUSED_LOCKED | If AF successful |
  656. *| | | | Lens now locked |
  657. *+--------------------+---------------+--------------------+------------------+
  658. *| ACTIVE_SCAN | AF sweep done | NOT_FOCUSED_LOCKED | If AF successful |
  659. *| | | | Lens now locked |
  660. *+--------------------+---------------+--------------------+------------------+
  661. *| ACTIVE_SCAN | AF_CANCEL | INACTIVE | Cancel/reset AF |
  662. *| | | | Lens now locked |
  663. *+--------------------+---------------+--------------------+------------------+
  664. *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Cancel/reset AF |
  665. *+--------------------+---------------+--------------------+------------------+
  666. *| FOCUSED_LOCKED | AF_TRIGGER | ACTIVE_SCAN | Start new sweep |
  667. *| | | | Lens now moving |
  668. *+--------------------+---------------+--------------------+------------------+
  669. *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Cancel/reset AF |
  670. *+--------------------+---------------+--------------------+------------------+
  671. *| NOT_FOCUSED_LOCKED | AF_TRIGGER | ACTIVE_SCAN | Start new sweep |
  672. *| | | | Lens now moving |
  673. *+--------------------+---------------+--------------------+------------------+
  674. *| All states | mode change | INACTIVE | |
  675. *+--------------------+---------------+--------------------+------------------+
  676. *
  677. * mode = AF_MODE_CONTINUOUS_VIDEO
  678. *| state | trans. cause | new state | notes |
  679. *+--------------------+---------------+--------------------+------------------+
  680. *| INACTIVE | HAL initiates | PASSIVE_SCAN | Start AF scan |
  681. *| | new scan | | Lens now moving |
  682. *+--------------------+---------------+--------------------+------------------+
  683. *| INACTIVE | AF_TRIGGER | NOT_FOCUSED_LOCKED | AF state query |
  684. *| | | | Lens now locked |
  685. *+--------------------+---------------+--------------------+------------------+
  686. *| PASSIVE_SCAN | HAL completes | PASSIVE_FOCUSED | End AF scan |
  687. *| | current scan | | Lens now locked |
  688. *+--------------------+---------------+--------------------+------------------+
  689. *| PASSIVE_SCAN | HAL fails | PASSIVE_UNFOCUSED | End AF scan |
  690. *| | current scan | | Lens now locked |
  691. *+--------------------+---------------+--------------------+------------------+
  692. *| PASSIVE_SCAN | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
  693. *| | | | if focus is good |
  694. *| | | | Lens now locked |
  695. *+--------------------+---------------+--------------------+------------------+
  696. *| PASSIVE_SCAN | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
  697. *| | | | if focus is bad |
  698. *| | | | Lens now locked |
  699. *+--------------------+---------------+--------------------+------------------+
  700. *| PASSIVE_SCAN | AF_CANCEL | INACTIVE | Reset lens |
  701. *| | | | position |
  702. *| | | | Lens now locked |
  703. *+--------------------+---------------+--------------------+------------------+
  704. *| PASSIVE_FOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
  705. *| | new scan | | Lens now moving |
  706. *+--------------------+---------------+--------------------+------------------+
  707. *| PASSIVE_UNFOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
  708. *| | new scan | | Lens now moving |
  709. *+--------------------+---------------+--------------------+------------------+
  710. *| PASSIVE_FOCUSED | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
  711. *| | | | Lens now locked |
  712. *+--------------------+---------------+--------------------+------------------+
  713. *| PASSIVE_UNFOCUSED | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
  714. *| | | | Lens now locked |
  715. *+--------------------+---------------+--------------------+------------------+
  716. *| FOCUSED_LOCKED | AF_TRIGGER | FOCUSED_LOCKED | No effect |
  717. *+--------------------+---------------+--------------------+------------------+
  718. *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
  719. *+--------------------+---------------+--------------------+------------------+
  720. *| NOT_FOCUSED_LOCKED | AF_TRIGGER | NOT_FOCUSED_LOCKED | No effect |
  721. *+--------------------+---------------+--------------------+------------------+
  722. *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
  723. *+--------------------+---------------+--------------------+------------------+
  724. *
  725. * mode = AF_MODE_CONTINUOUS_PICTURE
  726. *| state | trans. cause | new state | notes |
  727. *+--------------------+---------------+--------------------+------------------+
  728. *| INACTIVE | HAL initiates | PASSIVE_SCAN | Start AF scan |
  729. *| | new scan | | Lens now moving |
  730. *+--------------------+---------------+--------------------+------------------+
  731. *| INACTIVE | AF_TRIGGER | NOT_FOCUSED_LOCKED | AF state query |
  732. *| | | | Lens now locked |
  733. *+--------------------+---------------+--------------------+------------------+
  734. *| PASSIVE_SCAN | HAL completes | PASSIVE_FOCUSED | End AF scan |
  735. *| | current scan | | Lens now locked |
  736. *+--------------------+---------------+--------------------+------------------+
  737. *| PASSIVE_SCAN | HAL fails | PASSIVE_UNFOCUSED | End AF scan |
  738. *| | current scan | | Lens now locked |
  739. *+--------------------+---------------+--------------------+------------------+
  740. *| PASSIVE_SCAN | AF_TRIGGER | FOCUSED_LOCKED | Eventual trans. |
  741. *| | | | once focus good |
  742. *| | | | Lens now locked |
  743. *+--------------------+---------------+--------------------+------------------+
  744. *| PASSIVE_SCAN | AF_TRIGGER | NOT_FOCUSED_LOCKED | Eventual trans. |
  745. *| | | | if cannot focus |
  746. *| | | | Lens now locked |
  747. *+--------------------+---------------+--------------------+------------------+
  748. *| PASSIVE_SCAN | AF_CANCEL | INACTIVE | Reset lens |
  749. *| | | | position |
  750. *| | | | Lens now locked |
  751. *+--------------------+---------------+--------------------+------------------+
  752. *| PASSIVE_FOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
  753. *| | new scan | | Lens now moving |
  754. *+--------------------+---------------+--------------------+------------------+
  755. *| PASSIVE_UNFOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
  756. *| | new scan | | Lens now moving |
  757. *+--------------------+---------------+--------------------+------------------+
  758. *| PASSIVE_FOCUSED | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
  759. *| | | | Lens now locked |
  760. *+--------------------+---------------+--------------------+------------------+
  761. *| PASSIVE_UNFOCUSED | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
  762. *| | | | Lens now locked |
  763. *+--------------------+---------------+--------------------+------------------+
  764. *| FOCUSED_LOCKED | AF_TRIGGER | FOCUSED_LOCKED | No effect |
  765. *+--------------------+---------------+--------------------+------------------+
  766. *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
  767. *+--------------------+---------------+--------------------+------------------+
  768. *| NOT_FOCUSED_LOCKED | AF_TRIGGER | NOT_FOCUSED_LOCKED | No effect |
  769. *+--------------------+---------------+--------------------+------------------+
  770. *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
  771. *+--------------------+---------------+--------------------+------------------+
  772. *
  773. * S4.6. AE and AWB state machines
  774. *
  775. * The AE and AWB state machines are mostly identical. AE has additional
  776. * FLASH_REQUIRED and PRECAPTURE states. So rows below that refer to those two
  777. * states should be ignored for the AWB state machine.
  778. *
  779. * when enabling AE/AWB or changing AE/AWB mode
  780. *| state | trans. cause | new state | notes |
  781. *+--------------------+---------------+--------------------+------------------+
  782. *| Any | mode change | INACTIVE | |
  783. *+--------------------+---------------+--------------------+------------------+
  784. *
  785. * mode = AE_MODE_OFF / AWB mode not AUTO
  786. *| state | trans. cause | new state | notes |
  787. *+--------------------+---------------+--------------------+------------------+
  788. *| INACTIVE | | INACTIVE | AE/AWB disabled |
  789. *+--------------------+---------------+--------------------+------------------+
  790. *
  791. * mode = AE_MODE_ON_* / AWB_MODE_AUTO
  792. *| state | trans. cause | new state | notes |
  793. *+--------------------+---------------+--------------------+------------------+
  794. *| INACTIVE | HAL initiates | SEARCHING | |
  795. *| | AE/AWB scan | | |
  796. *+--------------------+---------------+--------------------+------------------+
  797. *| INACTIVE | AE/AWB_LOCK | LOCKED | values locked |
  798. *| | on | | |
  799. *+--------------------+---------------+--------------------+------------------+
  800. *| SEARCHING | HAL finishes | CONVERGED | good values, not |
  801. *| | AE/AWB scan | | changing |
  802. *+--------------------+---------------+--------------------+------------------+
  803. *| SEARCHING | HAL finishes | FLASH_REQUIRED | converged but too|
  804. *| | AE scan | | dark w/o flash |
  805. *+--------------------+---------------+--------------------+------------------+
  806. *| SEARCHING | AE/AWB_LOCK | LOCKED | values locked |
  807. *| | on | | |
  808. *+--------------------+---------------+--------------------+------------------+
  809. *| CONVERGED | HAL initiates | SEARCHING | values locked |
  810. *| | AE/AWB scan | | |
  811. *+--------------------+---------------+--------------------+------------------+
  812. *| CONVERGED | AE/AWB_LOCK | LOCKED | values locked |
  813. *| | on | | |
  814. *+--------------------+---------------+--------------------+------------------+
  815. *| FLASH_REQUIRED | HAL initiates | SEARCHING | values locked |
  816. *| | AE/AWB scan | | |
  817. *+--------------------+---------------+--------------------+------------------+
  818. *| FLASH_REQUIRED | AE/AWB_LOCK | LOCKED | values locked |
  819. *| | on | | |
  820. *+--------------------+---------------+--------------------+------------------+
  821. *| LOCKED | AE/AWB_LOCK | SEARCHING | values not good |
  822. *| | off | | after unlock |
  823. *+--------------------+---------------+--------------------+------------------+
  824. *| LOCKED | AE/AWB_LOCK | CONVERGED | values good |
  825. *| | off | | after unlock |
  826. *+--------------------+---------------+--------------------+------------------+
  827. *| LOCKED | AE_LOCK | FLASH_REQUIRED | exposure good, |
  828. *| | off | | but too dark |
  829. *+--------------------+---------------+--------------------+------------------+
  830. *| All AE states | PRECAPTURE_ | PRECAPTURE | Start precapture |
  831. *| | START | | sequence |
  832. *+--------------------+---------------+--------------------+------------------+
  833. *| PRECAPTURE | Sequence done.| CONVERGED | Ready for high- |
  834. *| | AE_LOCK off | | quality capture |
  835. *+--------------------+---------------+--------------------+------------------+
  836. *| PRECAPTURE | Sequence done.| LOCKED | Ready for high- |
  837. *| | AE_LOCK on | | quality capture |
  838. *+--------------------+---------------+--------------------+------------------+
  839. *
  840. */
  841. /**
  842. * S5. Cropping:
  843. *
  844. * Cropping of the full pixel array (for digital zoom and other use cases where
  845. * a smaller FOV is desirable) is communicated through the
  846. * ANDROID_SCALER_CROP_REGION setting. This is a per-request setting, and can
  847. * change on a per-request basis, which is critical for implementing smooth
  848. * digital zoom.
  849. *
  850. * The region is defined as a rectangle (x, y, width, height), with (x, y)
  851. * describing the top-left corner of the rectangle. The rectangle is defined on
  852. * the coordinate system of the sensor active pixel array, with (0,0) being the
  853. * top-left pixel of the active pixel array. Therefore, the width and height
  854. * cannot be larger than the dimensions reported in the
  855. * ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY static info field. The minimum allowed
  856. * width and height are reported by the HAL through the
  857. * ANDROID_SCALER_MAX_DIGITAL_ZOOM static info field, which describes the
  858. * maximum supported zoom factor. Therefore, the minimum crop region width and
  859. * height are:
  860. *
  861. * {width, height} =
  862. * { floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[0] /
  863. * ANDROID_SCALER_MAX_DIGITAL_ZOOM),
  864. * floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[1] /
  865. * ANDROID_SCALER_MAX_DIGITAL_ZOOM) }
  866. *
  867. * If the crop region needs to fulfill specific requirements (for example, it
  868. * needs to start on even coordinates, and its width/height needs to be even),
  869. * the HAL must do the necessary rounding and write out the final crop region
  870. * used in the output result metadata. Similarly, if the HAL implements video
  871. * stabilization, it must adjust the result crop region to describe the region
  872. * actually included in the output after video stabilization is applied. In
  873. * general, a camera-using application must be able to determine the field of
  874. * view it is receiving based on the crop region, the dimensions of the image
  875. * sensor, and the lens focal length.
  876. *
  877. * It is assumed that the cropping is applied after raw to other color space
  878. * conversion. Raw streams (RAW16 and RAW_OPAQUE) don't have this conversion stage,
  879. * and are not croppable. Therefore, the crop region must be ignored by the HAL
  880. * for raw streams.
  881. *
  882. * Since the crop region applies to all non-raw streams, which may have different aspect
  883. * ratios than the crop region, the exact sensor region used for each stream may
  884. * be smaller than the crop region. Specifically, each stream should maintain
  885. * square pixels and its aspect ratio by minimally further cropping the defined
  886. * crop region. If the stream's aspect ratio is wider than the crop region, the
  887. * stream should be further cropped vertically, and if the stream's aspect ratio
  888. * is narrower than the crop region, the stream should be further cropped
  889. * horizontally.
  890. *
  891. * In all cases, the stream crop must be centered within the full crop region,
  892. * and each stream is only either cropped horizontally or vertical relative to
  893. * the full crop region, never both.
  894. *
  895. * For example, if two streams are defined, a 640x480 stream (4:3 aspect), and a
  896. * 1280x720 stream (16:9 aspect), below demonstrates the expected output regions
  897. * for each stream for a few sample crop regions, on a hypothetical 3 MP (2000 x
  898. * 1500 pixel array) sensor.
  899. *
  900. * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
  901. *
  902. * 640x480 stream crop: (500, 375, 1000, 750) (equal to crop region)
  903. * 1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
  904. *
  905. * 0 1000 2000
  906. * +---------+---------+---------+----------+
  907. * | Active pixel array |
  908. * | |
  909. * | |
  910. * + +-------------------+ + 375
  911. * | | | |
  912. * | O===================O |
  913. * | I 1280x720 stream I |
  914. * + I I + 750
  915. * | I I |
  916. * | O===================O |
  917. * | | | |
  918. * + +-------------------+ + 1125
  919. * | Crop region, 640x480 stream |
  920. * | |
  921. * | |
  922. * +---------+---------+---------+----------+ 1500
  923. *
  924. * Crop region: (500, 375, 1333, 750) (16:9 aspect ratio)
  925. *
  926. * 640x480 stream crop: (666, 375, 1000, 750) (marked with =)
  927. * 1280x720 stream crop: (500, 375, 1333, 750) (equal to crop region)
  928. *
  929. * 0 1000 2000
  930. * +---------+---------+---------+----------+
  931. * | Active pixel array |
  932. * | |
  933. * | |
  934. * + +---O==================O---+ + 375
  935. * | | I 640x480 stream I | |
  936. * | | I I | |
  937. * | | I I | |
  938. * + | I I | + 750
  939. * | | I I | |
  940. * | | I I | |
  941. * | | I I | |
  942. * + +---O==================O---+ + 1125
  943. * | Crop region, 1280x720 stream |
  944. * | |
  945. * | |
  946. * +---------+---------+---------+----------+ 1500
  947. *
  948. * Crop region: (500, 375, 750, 750) (1:1 aspect ratio)
  949. *
  950. * 640x480 stream crop: (500, 469, 750, 562) (marked with =)
  951. * 1280x720 stream crop: (500, 543, 750, 414) (marged with #)
  952. *
  953. * 0 1000 2000
  954. * +---------+---------+---------+----------+
  955. * | Active pixel array |
  956. * | |
  957. * | |
  958. * + +--------------+ + 375
  959. * | O==============O |
  960. * | ################ |
  961. * | # # |
  962. * + # # + 750
  963. * | # # |
  964. * | ################ 1280x720 |
  965. * | O==============O 640x480 |
  966. * + +--------------+ + 1125
  967. * | Crop region |
  968. * | |
  969. * | |
  970. * +---------+---------+---------+----------+ 1500
  971. *
  972. * And a final example, a 1024x1024 square aspect ratio stream instead of the
  973. * 480p stream:
  974. *
  975. * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
  976. *
  977. * 1024x1024 stream crop: (625, 375, 750, 750) (marked with #)
  978. * 1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
  979. *
  980. * 0 1000 2000
  981. * +---------+---------+---------+----------+
  982. * | Active pixel array |
  983. * | |
  984. * | 1024x1024 stream |
  985. * + +--###############--+ + 375
  986. * | | # # | |
  987. * | O===================O |
  988. * | I 1280x720 stream I |
  989. * + I I + 750
  990. * | I I |
  991. * | O===================O |
  992. * | | # # | |
  993. * + +--###############--+ + 1125
  994. * | Crop region |
  995. * | |
  996. * | |
  997. * +---------+---------+---------+----------+ 1500
  998. *
  999. */
  1000. /**
  1001. * S6. Error management:
  1002. *
  1003. * Camera HAL device ops functions that have a return value will all return
  1004. * -ENODEV / NULL in case of a serious error. This means the device cannot
  1005. * continue operation, and must be closed by the framework. Once this error is
  1006. * returned by some method, or if notify() is called with ERROR_DEVICE, only
  1007. * the close() method can be called successfully. All other methods will return
  1008. * -ENODEV / NULL.
  1009. *
  1010. * If a device op is called in the wrong sequence, for example if the framework
  1011. * calls configure_streams() is called before initialize(), the device must
  1012. * return -ENOSYS from the call, and do nothing.
  1013. *
  1014. * Transient errors in image capture must be reported through notify() as follows:
  1015. *
  1016. * - The failure of an entire capture to occur must be reported by the HAL by
  1017. * calling notify() with ERROR_REQUEST. Individual errors for the result
  1018. * metadata or the output buffers must not be reported in this case.
  1019. *
  1020. * - If the metadata for a capture cannot be produced, but some image buffers
  1021. * were filled, the HAL must call notify() with ERROR_RESULT.
  1022. *
  1023. * - If an output image buffer could not be filled, but either the metadata was
  1024. * produced or some other buffers were filled, the HAL must call notify() with
  1025. * ERROR_BUFFER for each failed buffer.
  1026. *
  1027. * In each of these transient failure cases, the HAL must still call
  1028. * process_capture_result, with valid output and input (if an input buffer was
  1029. * submitted) buffer_handle_t. If the result metadata could not be produced, it
  1030. * should be NULL. If some buffers could not be filled, they must be returned with
  1031. * process_capture_result in the error state, their release fences must be set to
  1032. * the acquire fences passed by the framework, or -1 if they have been waited on by
  1033. * the HAL already.
  1034. *
  1035. * Invalid input arguments result in -EINVAL from the appropriate methods. In
  1036. * that case, the framework must act as if that call had never been made.
  1037. *
  1038. */
  1039. /**
  1040. * S7. Key Performance Indicator (KPI) glossary:
  1041. *
  1042. * This includes some critical definitions that are used by KPI metrics.
  1043. *
  1044. * Pipeline Latency:
  1045. * For a given capture request, the duration from the framework calling
  1046. * process_capture_request to the HAL sending capture result and all buffers
  1047. * back by process_capture_result call. To make the Pipeline Latency measure
  1048. * independent of frame rate, it is measured by frame count.
  1049. *
  1050. * For example, when frame rate is 30 (fps), the frame duration (time interval
  1051. * between adjacent frame capture time) is 33 (ms).
  1052. * If it takes 5 frames for framework to get the result and buffers back for
  1053. * a given request, then the Pipeline Latency is 5 (frames), instead of
  1054. * 5 x 33 = 165 (ms).
  1055. *
  1056. * The Pipeline Latency is determined by android.request.pipelineDepth and
  1057. * android.request.pipelineMaxDepth, see their definitions for more details.
  1058. *
  1059. */
  1060. /**
  1061. * S8. Sample Use Cases:
  1062. *
  1063. * This includes some typical use case examples the camera HAL may support.
  1064. *
  1065. * S8.1 Zero Shutter Lag (ZSL) with CAMERA3_STREAM_INPUT stream.
  1066. *
  1067. * When Zero Shutter Lag (ZSL) is supported by the camera device, the INPUT stream
  1068. * can be used for application/framework implemented ZSL use case. This kind of stream
  1069. * will be used by the framework as follows:
  1070. *
  1071. * 1. Framework configures an opaque raw format output stream that is used to
  1072. * produce the ZSL output buffers. The stream pixel format will be
  1073. * HAL_PIXEL_FORMAT_RAW_OPAQUE.
  1074. *
  1075. * 2. Framework configures an opaque raw format input stream that is used to
  1076. * send the reprocess ZSL buffers to the HAL. The stream pixel format will
  1077. * also be HAL_PIXEL_FORMAT_RAW_OPAQUE.
  1078. *
  1079. * 3. Framework configures a YUV/JPEG output stream that is used to receive the
  1080. * reprocessed data. The stream pixel format will be YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
  1081. *
  1082. * 4. Framework picks a ZSL buffer from the output stream when a ZSL capture is
  1083. * issued by the application, and sends the data back as an input buffer in a
  1084. * reprocessing request, then sends to the HAL for reprocessing.
  1085. *
  1086. * 5. The HAL sends back the output JPEG result to framework.
  1087. *
  1088. * The HAL can select the actual raw buffer format and configure the ISP pipeline
  1089. * appropriately based on the HAL_PIXEL_FORMAT_RAW_OPAQUE format. See this format
  1090. * definition for more details.
  1091. *
  1092. * S8.2 Zero Shutter Lag (ZSL) with CAMERA3_STREAM_BIDIRECTIONAL stream.
  1093. *
  1094. * For this use case, the bidirectional stream will be used by the framework as follows:
  1095. *
  1096. * 1. The framework includes a buffer from this stream as output buffer in a
  1097. * request as normal.
  1098. *
  1099. * 2. Once the HAL device returns a filled output buffer to the framework,
  1100. * the framework may do one of two things with the filled buffer:
  1101. *
  1102. * 2. a. The framework uses the filled data, and returns the now-used buffer
  1103. * to the stream queue for reuse. This behavior exactly matches the
  1104. * OUTPUT type of stream.
  1105. *
  1106. * 2. b. The framework wants to reprocess the filled data, and uses the
  1107. * buffer as an input buffer for a request. Once the HAL device has
  1108. * used the reprocessing buffer, it then returns it to the
  1109. * framework. The framework then returns the now-used buffer to the
  1110. * stream queue for reuse.
  1111. *
  1112. * 3. The HAL device will be given the buffer again as an output buffer for
  1113. * a request at some future point.
  1114. *
  1115. * For ZSL use case, the pixel format for bidirectional stream will be
  1116. * HAL_PIXEL_FORMAT_RAW_OPAQUE or HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED if it
  1117. * is listed in android.scaler.availableInputOutputFormatsMap. When
  1118. * HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, the gralloc
  1119. * usage flags for the consumer endpoint will be set to GRALLOC_USAGE_HW_CAMERA_ZSL.
  1120. * A configuration stream list that has BIDIRECTIONAL stream used as input, will
  1121. * usually also have a distinct OUTPUT stream to get the reprocessing data. For example,
  1122. * for the ZSL use case, the stream list might be configured with the following:
  1123. *
  1124. * - A HAL_PIXEL_FORMAT_RAW_OPAQUE bidirectional stream is used
  1125. * as input.
  1126. * - And a HAL_PIXEL_FORMAT_BLOB (JPEG) output stream.
  1127. *
  1128. */
  1129. /**
  1130. * S9. Notes on Controls and Metadata
  1131. *
  1132. * This section contains notes about the interpretation and usage of various metadata tags.
  1133. *
  1134. * S9.1 HIGH_QUALITY and FAST modes.
  1135. *
  1136. * Many camera post-processing blocks may be listed as having HIGH_QUALITY,
  1137. * FAST, and OFF operating modes. These blocks will typically also have an
  1138. * 'available modes' tag representing which of these operating modes are
  1139. * available on a given device. The general policy regarding implementing
  1140. * these modes is as follows:
  1141. *
  1142. * 1. Operating mode controls of hardware blocks that cannot be disabled
  1143. * must not list OFF in their corresponding 'available modes' tags.
  1144. *
  1145. * 2. OFF will always be included in their corresponding 'available modes'
  1146. * tag if it is possible to disable that hardware block.
  1147. *
  1148. * 3. FAST must always be included in the 'available modes' tags for all
  1149. * post-processing blocks supported on the device. If a post-processing
  1150. * block also has a slower and higher quality operating mode that does
  1151. * not meet the framerate requirements for FAST mode, HIGH_QUALITY should
  1152. * be included in the 'available modes' tag to represent this operating
  1153. * mode.
  1154. */
  1155. __BEGIN_DECLS
  1156. struct camera3_device;
  1157. /**********************************************************************
  1158. *
  1159. * Camera3 stream and stream buffer definitions.
  1160. *
  1161. * These structs and enums define the handles and contents of the input and
  1162. * output streams connecting the HAL to various framework and application buffer
  1163. * consumers. Each stream is backed by a gralloc buffer queue.
  1164. *
  1165. */
  1166. /**
  1167. * camera3_stream_type_t:
  1168. *
  1169. * The type of the camera stream, which defines whether the camera HAL device is
  1170. * the producer or the consumer for that stream, and how the buffers of the
  1171. * stream relate to the other streams.
  1172. */
  1173. typedef enum camera3_stream_type {
  1174. /**
  1175. * This stream is an output stream; the camera HAL device will be
  1176. * responsible for filling buffers from this stream with newly captured or
  1177. * reprocessed image data.
  1178. */
  1179. CAMERA3_STREAM_OUTPUT = 0,
  1180. /**
  1181. * This stream is an input stream; the camera HAL device will be responsible
  1182. * for reading buffers from this stream and sending them through the camera
  1183. * processing pipeline, as if the buffer was a newly captured image from the
  1184. * imager.
  1185. *
  1186. * The pixel format for input stream can be any format reported by
  1187. * android.scaler.availableInputOutputFormatsMap. The pixel format of the
  1188. * output stream that is used to produce the reprocessing data may be any
  1189. * format reported by android.scaler.availableStreamConfigurations. The
  1190. * supported input/output stream combinations depends the camera device
  1191. * capabilities, see android.scaler.availableInputOutputFormatsMap for
  1192. * stream map details.
  1193. *
  1194. * This kind of stream is generally used to reprocess data into higher
  1195. * quality images (that otherwise would cause a frame rate performance
  1196. * loss), or to do off-line reprocessing.
  1197. *
  1198. * A typical use case is Zero Shutter Lag (ZSL), see S8.1 for more details.
  1199. *
  1200. */
  1201. CAMERA3_STREAM_INPUT = 1,
  1202. /**
  1203. * This stream can be used for input and output. Typically, the stream is
  1204. * used as an output stream, but occasionally one already-filled buffer may
  1205. * be sent back to the HAL device for reprocessing.
  1206. *
  1207. * This kind of stream is meant generally for Zero Shutter Lag (ZSL)
  1208. * features, where copying the captured image from the output buffer to the
  1209. * reprocessing input buffer would be expensive. See S8.2 for more details.
  1210. *
  1211. * Note that the HAL will always be reprocessing data it produced.
  1212. *
  1213. */
  1214. CAMERA3_STREAM_BIDIRECTIONAL = 2,
  1215. /**
  1216. * Total number of framework-defined stream types
  1217. */
  1218. CAMERA3_NUM_STREAM_TYPES
  1219. } camera3_stream_type_t;
  1220. /**
  1221. * camera3_stream_t:
  1222. *
  1223. * A handle to a single camera input or output stream. A stream is defined by
  1224. * the framework by its buffer resolution and format, and additionally by the
  1225. * HAL with the gralloc usage flags and the maximum in-flight buffer count.
  1226. *
  1227. * The stream structures are owned by the framework, but pointers to a
  1228. * camera3_stream passed into the HAL by configure_streams() are valid until the
  1229. * end of the first subsequent configure_streams() call that _does not_ include
  1230. * that camera3_stream as an argument, or until the end of the close() call.
  1231. *
  1232. * All camera3_stream framework-controlled members are immutable once the
  1233. * camera3_stream is passed into configure_streams(). The HAL may only change
  1234. * the HAL-controlled parameters during a configure_streams() call, except for
  1235. * the contents of the private pointer.
  1236. *
  1237. * If a configure_streams() call returns a non-fatal error, all active streams
  1238. * remain valid as if configure_streams() had not been called.
  1239. *
  1240. * The endpoint of the stream is not visible to the camera HAL device.
  1241. * In DEVICE_API_VERSION_3_1, this was changed to share consumer usage flags
  1242. * on streams where the camera is a producer (OUTPUT and BIDIRECTIONAL stream
  1243. * types) see the usage field below.
  1244. */
  1245. typedef struct camera3_stream {
  1246. /*****
  1247. * Set by framework before configure_streams()
  1248. */
  1249. /**
  1250. * The type of the stream, one of the camera3_stream_type_t values.
  1251. */
  1252. int stream_type;
  1253. /**
  1254. * The width in pixels of the buffers in this stream
  1255. */
  1256. uint32_t width;
  1257. /**
  1258. * The height in pixels of the buffers in this stream
  1259. */
  1260. uint32_t height;
  1261. /**
  1262. * The pixel format for the buffers in this stream. Format is a value from
  1263. * the HAL_PIXEL_FORMAT_* list in system/core/include/system/graphics.h, or
  1264. * from device-specific headers.
  1265. *
  1266. * If HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, then the platform
  1267. * gralloc module will select a format based on the usage flags provided by
  1268. * the camera device and the other endpoint of the stream.
  1269. *
  1270. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1271. *
  1272. * The camera HAL device must inspect the buffers handed to it in the
  1273. * subsequent register_stream_buffers() call to obtain the
  1274. * implementation-specific format details, if necessary.
  1275. *
  1276. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1277. *
  1278. * register_stream_buffers() won't be called by the framework, so the HAL
  1279. * should configure the ISP and sensor pipeline based purely on the sizes,
  1280. * usage flags, and formats for the configured streams.
  1281. */
  1282. int format;
  1283. /*****
  1284. * Set by HAL during configure_streams().
  1285. */
  1286. /**
  1287. * The gralloc usage flags for this stream, as needed by the HAL. The usage
  1288. * flags are defined in gralloc.h (GRALLOC_USAGE_*), or in device-specific
  1289. * headers.
  1290. *
  1291. * For output streams, these are the HAL's producer usage flags. For input
  1292. * streams, these are the HAL's consumer usage flags. The usage flags from
  1293. * the producer and the consumer will be combined together and then passed
  1294. * to the platform gralloc HAL module for allocating the gralloc buffers for
  1295. * each stream.
  1296. *
  1297. * Version information:
  1298. *
  1299. * == CAMERA_DEVICE_API_VERSION_3_0:
  1300. *
  1301. * No initial value guaranteed when passed via configure_streams().
  1302. * HAL may not use this field as input, and must write over this field
  1303. * with its usage flags.
  1304. *
  1305. * >= CAMERA_DEVICE_API_VERSION_3_1:
  1306. *
  1307. * For stream_type OUTPUT and BIDIRECTIONAL, when passed via
  1308. * configure_streams(), the initial value of this is the consumer's
  1309. * usage flags. The HAL may use these consumer flags to decide stream
  1310. * configuration.
  1311. * For stream_type INPUT, when passed via configure_streams(), the initial
  1312. * value of this is 0.
  1313. * For all streams passed via configure_streams(), the HAL must write
  1314. * over this field with its usage flags.
  1315. */
  1316. uint32_t usage;
  1317. /**
  1318. * The maximum number of buffers the HAL device may need to have dequeued at
  1319. * the same time. The HAL device may not have more buffers in-flight from
  1320. * this stream than this value.
  1321. */
  1322. uint32_t max_buffers;
  1323. /**
  1324. * A handle to HAL-private information for the stream. Will not be inspected
  1325. * by the framework code.
  1326. */
  1327. void *priv;
  1328. } camera3_stream_t;
  1329. /**
  1330. * camera3_stream_configuration_t:
  1331. *
  1332. * A structure of stream definitions, used by configure_streams(). This
  1333. * structure defines all the output streams and the reprocessing input
  1334. * stream for the current camera use case.
  1335. */
  1336. typedef struct camera3_stream_configuration {
  1337. /**
  1338. * The total number of streams requested by the framework. This includes
  1339. * both input and output streams. The number of streams will be at least 1,
  1340. * and there will be at least one output-capable stream.
  1341. */
  1342. uint32_t num_streams;
  1343. /**
  1344. * An array of camera stream pointers, defining the input/output
  1345. * configuration for the camera HAL device.
  1346. *
  1347. * At most one input-capable stream may be defined (INPUT or BIDIRECTIONAL)
  1348. * in a single configuration.
  1349. *
  1350. * At least one output-capable stream must be defined (OUTPUT or
  1351. * BIDIRECTIONAL).
  1352. */
  1353. camera3_stream_t **streams;
  1354. } camera3_stream_configuration_t;
  1355. /**
  1356. * camera3_buffer_status_t:
  1357. *
  1358. * The current status of a single stream buffer.
  1359. */
  1360. typedef enum camera3_buffer_status {
  1361. /**
  1362. * The buffer is in a normal state, and can be used after waiting on its
  1363. * sync fence.
  1364. */
  1365. CAMERA3_BUFFER_STATUS_OK = 0,
  1366. /**
  1367. * The buffer does not contain valid data, and the data in it should not be
  1368. * used. The sync fence must still be waited on before reusing the buffer.
  1369. */
  1370. CAMERA3_BUFFER_STATUS_ERROR = 1
  1371. } camera3_buffer_status_t;
  1372. /**
  1373. * camera3_stream_buffer_t:
  1374. *
  1375. * A single buffer from a camera3 stream. It includes a handle to its parent
  1376. * stream, the handle to the gralloc buffer itself, and sync fences
  1377. *
  1378. * The buffer does not specify whether it is to be used for input or output;
  1379. * that is determined by its parent stream type and how the buffer is passed to
  1380. * the HAL device.
  1381. */
  1382. typedef struct camera3_stream_buffer {
  1383. /**
  1384. * The handle of the stream this buffer is associated with
  1385. */
  1386. camera3_stream_t *stream;
  1387. /**
  1388. * The native handle to the buffer
  1389. */
  1390. buffer_handle_t *buffer;
  1391. /**
  1392. * Current state of the buffer, one of the camera3_buffer_status_t
  1393. * values. The framework will not pass buffers to the HAL that are in an
  1394. * error state. In case a buffer could not be filled by the HAL, it must
  1395. * have its status set to CAMERA3_BUFFER_STATUS_ERROR when returned to the
  1396. * framework with process_capture_result().
  1397. */
  1398. int status;
  1399. /**
  1400. * The acquire sync fence for this buffer. The HAL must wait on this fence
  1401. * fd before attempting to read from or write to this buffer.
  1402. *
  1403. * The framework may be set to -1 to indicate that no waiting is necessary
  1404. * for this buffer.
  1405. *
  1406. * When the HAL returns an output buffer to the framework with
  1407. * process_capture_result(), the acquire_fence must be set to -1. If the HAL
  1408. * never waits on the acquire_fence due to an error in filling a buffer,
  1409. * when calling process_capture_result() the HAL must set the release_fence
  1410. * of the buffer to be the acquire_fence passed to it by the framework. This
  1411. * will allow the framework to wait on the fence before reusing the buffer.
  1412. *
  1413. * For input buffers, the HAL must not change the acquire_fence field during
  1414. * the process_capture_request() call.
  1415. *
  1416. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1417. *
  1418. * When the HAL returns an input buffer to the framework with
  1419. * process_capture_result(), the acquire_fence must be set to -1. If the HAL
  1420. * never waits on input buffer acquire fence due to an error, the sync
  1421. * fences should be handled similarly to the way they are handled for output
  1422. * buffers.
  1423. */
  1424. int acquire_fence;
  1425. /**
  1426. * The release sync fence for this buffer. The HAL must set this fence when
  1427. * returning buffers to the framework, or write -1 to indicate that no
  1428. * waiting is required for this buffer.
  1429. *
  1430. * For the output buffers, the fences must be set in the output_buffers
  1431. * array passed to process_capture_result().
  1432. *
  1433. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1434. *
  1435. * For the input buffer, the release fence must be set by the
  1436. * process_capture_request() call.
  1437. *
  1438. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1439. *
  1440. * For the input buffer, the fences must be set in the input_buffer
  1441. * passed to process_capture_result().
  1442. *
  1443. * After signaling the release_fence for this buffer, the HAL
  1444. * should not make any further attempts to access this buffer as the
  1445. * ownership has been fully transferred back to the framework.
  1446. *
  1447. * If a fence of -1 was specified then the ownership of this buffer
  1448. * is transferred back immediately upon the call of process_capture_result.
  1449. */
  1450. int release_fence;
  1451. } camera3_stream_buffer_t;
  1452. /**
  1453. * camera3_stream_buffer_set_t:
  1454. *
  1455. * The complete set of gralloc buffers for a stream. This structure is given to
  1456. * register_stream_buffers() to allow the camera HAL device to register/map/etc
  1457. * newly allocated stream buffers.
  1458. *
  1459. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1460. *
  1461. * Deprecated (and not used). In particular,
  1462. * register_stream_buffers is also deprecated and will never be invoked.
  1463. *
  1464. */
  1465. typedef struct camera3_stream_buffer_set {
  1466. /**
  1467. * The stream handle for the stream these buffers belong to
  1468. */
  1469. camera3_stream_t *stream;
  1470. /**
  1471. * The number of buffers in this stream. It is guaranteed to be at least
  1472. * stream->max_buffers.
  1473. */
  1474. uint32_t num_buffers;
  1475. /**
  1476. * The array of gralloc buffer handles for this stream. If the stream format
  1477. * is set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, the camera HAL device
  1478. * should inspect the passed-in buffers to determine any platform-private
  1479. * pixel format information.
  1480. */
  1481. buffer_handle_t **buffers;
  1482. } camera3_stream_buffer_set_t;
  1483. /**
  1484. * camera3_jpeg_blob:
  1485. *
  1486. * Transport header for compressed JPEG buffers in output streams.
  1487. *
  1488. * To capture JPEG images, a stream is created using the pixel format
  1489. * HAL_PIXEL_FORMAT_BLOB. The buffer size for the stream is calculated by the
  1490. * framework, based on the static metadata field android.jpeg.maxSize. Since
  1491. * compressed JPEG images are of variable size, the HAL needs to include the
  1492. * final size of the compressed image using this structure inside the output
  1493. * stream buffer. The JPEG blob ID field must be set to CAMERA3_JPEG_BLOB_ID.
  1494. *
  1495. * Transport header should be at the end of the JPEG output stream buffer. That
  1496. * means the jpeg_blob_id must start at byte[buffer_size -
  1497. * sizeof(camera3_jpeg_blob)], where the buffer_size is the size of gralloc buffer.
  1498. * Any HAL using this transport header must account for it in android.jpeg.maxSize
  1499. * The JPEG data itself starts at the beginning of the buffer and should be
  1500. * jpeg_size bytes long.
  1501. */
  1502. typedef struct camera3_jpeg_blob {
  1503. uint16_t jpeg_blob_id;
  1504. uint32_t jpeg_size;
  1505. } camera3_jpeg_blob_t;
  1506. enum {
  1507. CAMERA3_JPEG_BLOB_ID = 0x00FF
  1508. };
  1509. /**********************************************************************
  1510. *
  1511. * Message definitions for the HAL notify() callback.
  1512. *
  1513. * These definitions are used for the HAL notify callback, to signal
  1514. * asynchronous events from the HAL device to the Android framework.
  1515. *
  1516. */
  1517. /**
  1518. * camera3_msg_type:
  1519. *
  1520. * Indicates the type of message sent, which specifies which member of the
  1521. * message union is valid.
  1522. *
  1523. */
  1524. typedef enum camera3_msg_type {
  1525. /**
  1526. * An error has occurred. camera3_notify_msg.message.error contains the
  1527. * error information.
  1528. */
  1529. CAMERA3_MSG_ERROR = 1,
  1530. /**
  1531. * The exposure of a given request has
  1532. * begun. camera3_notify_msg.message.shutter contains the information
  1533. * the capture.
  1534. */
  1535. CAMERA3_MSG_SHUTTER = 2,
  1536. /**
  1537. * Number of framework message types
  1538. */
  1539. CAMERA3_NUM_MESSAGES
  1540. } camera3_msg_type_t;
  1541. /**
  1542. * Defined error codes for CAMERA_MSG_ERROR
  1543. */
  1544. typedef enum camera3_error_msg_code {
  1545. /**
  1546. * A serious failure occured. No further frames or buffer streams will
  1547. * be produced by the device. Device should be treated as closed. The
  1548. * client must reopen the device to use it again. The frame_number field
  1549. * is unused.
  1550. */
  1551. CAMERA3_MSG_ERROR_DEVICE = 1,
  1552. /**
  1553. * An error has occurred in processing a request. No output (metadata or
  1554. * buffers) will be produced for this request. The frame_number field
  1555. * specifies which request has been dropped. Subsequent requests are
  1556. * unaffected, and the device remains operational.
  1557. */
  1558. CAMERA3_MSG_ERROR_REQUEST = 2,
  1559. /**
  1560. * An error has occurred in producing an output result metadata buffer
  1561. * for a request, but output stream buffers for it will still be
  1562. * available. Subsequent requests are unaffected, and the device remains
  1563. * operational. The frame_number field specifies the request for which
  1564. * result metadata won't be available.
  1565. */
  1566. CAMERA3_MSG_ERROR_RESULT = 3,
  1567. /**
  1568. * An error has occurred in placing an output buffer into a stream for a
  1569. * request. The frame metadata and other buffers may still be
  1570. * available. Subsequent requests are unaffected, and the device remains
  1571. * operational. The frame_number field specifies the request for which the
  1572. * buffer was dropped, and error_stream contains a pointer to the stream
  1573. * that dropped the frame.u
  1574. */
  1575. CAMERA3_MSG_ERROR_BUFFER = 4,
  1576. /**
  1577. * Number of error types
  1578. */
  1579. CAMERA3_MSG_NUM_ERRORS
  1580. } camera3_error_msg_code_t;
  1581. /**
  1582. * camera3_error_msg_t:
  1583. *
  1584. * Message contents for CAMERA3_MSG_ERROR
  1585. */
  1586. typedef struct camera3_error_msg {
  1587. /**
  1588. * Frame number of the request the error applies to. 0 if the frame number
  1589. * isn't applicable to the error.
  1590. */
  1591. uint32_t frame_number;
  1592. /**
  1593. * Pointer to the stream that had a failure. NULL if the stream isn't
  1594. * applicable to the error.
  1595. */
  1596. camera3_stream_t *error_stream;
  1597. /**
  1598. * The code for this error; one of the CAMERA_MSG_ERROR enum values.
  1599. */
  1600. int error_code;
  1601. } camera3_error_msg_t;
  1602. /**
  1603. * camera3_shutter_msg_t:
  1604. *
  1605. * Message contents for CAMERA3_MSG_SHUTTER
  1606. */
  1607. typedef struct camera3_shutter_msg {
  1608. /**
  1609. * Frame number of the request that has begun exposure
  1610. */
  1611. uint32_t frame_number;
  1612. /**
  1613. * Timestamp for the start of capture. This must match the capture result
  1614. * metadata's sensor exposure start timestamp.
  1615. */
  1616. uint64_t timestamp;
  1617. } camera3_shutter_msg_t;
  1618. /**
  1619. * camera3_notify_msg_t:
  1620. *
  1621. * The message structure sent to camera3_callback_ops_t.notify()
  1622. */
  1623. typedef struct camera3_notify_msg {
  1624. /**
  1625. * The message type. One of camera3_notify_msg_type, or a private extension.
  1626. */
  1627. int type;
  1628. union {
  1629. /**
  1630. * Error message contents. Valid if type is CAMERA3_MSG_ERROR
  1631. */
  1632. camera3_error_msg_t error;
  1633. /**
  1634. * Shutter message contents. Valid if type is CAMERA3_MSG_SHUTTER
  1635. */
  1636. camera3_shutter_msg_t shutter;
  1637. /**
  1638. * Generic message contents. Used to ensure a minimum size for custom
  1639. * message types.
  1640. */
  1641. uint8_t generic[32];
  1642. } message;
  1643. } camera3_notify_msg_t;
  1644. /**********************************************************************
  1645. *
  1646. * Capture request/result definitions for the HAL process_capture_request()
  1647. * method, and the process_capture_result() callback.
  1648. *
  1649. */
  1650. /**
  1651. * camera3_request_template_t:
  1652. *
  1653. * Available template types for
  1654. * camera3_device_ops.construct_default_request_settings()
  1655. */
  1656. typedef enum camera3_request_template {
  1657. /**
  1658. * Standard camera preview operation with 3A on auto.
  1659. */
  1660. CAMERA3_TEMPLATE_PREVIEW = 1,
  1661. /**
  1662. * Standard camera high-quality still capture with 3A and flash on auto.
  1663. */
  1664. CAMERA3_TEMPLATE_STILL_CAPTURE = 2,
  1665. /**
  1666. * Standard video recording plus preview with 3A on auto, torch off.
  1667. */
  1668. CAMERA3_TEMPLATE_VIDEO_RECORD = 3,
  1669. /**
  1670. * High-quality still capture while recording video. Application will
  1671. * include preview, video record, and full-resolution YUV or JPEG streams in
  1672. * request. Must not cause stuttering on video stream. 3A on auto.
  1673. */
  1674. CAMERA3_TEMPLATE_VIDEO_SNAPSHOT = 4,
  1675. /**
  1676. * Zero-shutter-lag mode. Application will request preview and
  1677. * full-resolution data for each frame, and reprocess it to JPEG when a
  1678. * still image is requested by user. Settings should provide highest-quality
  1679. * full-resolution images without compromising preview frame rate. 3A on
  1680. * auto.
  1681. */
  1682. CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG = 5,
  1683. /**
  1684. * A basic template for direct application control of capture
  1685. * parameters. All automatic control is disabled (auto-exposure, auto-white
  1686. * balance, auto-focus), and post-processing parameters are set to preview
  1687. * quality. The manual capture parameters (exposure, sensitivity, etc.)
  1688. * are set to reasonable defaults, but should be overridden by the
  1689. * application depending on the intended use case.
  1690. */
  1691. CAMERA3_TEMPLATE_MANUAL = 6,
  1692. /* Total number of templates */
  1693. CAMERA3_TEMPLATE_COUNT,
  1694. /**
  1695. * First value for vendor-defined request templates
  1696. */
  1697. CAMERA3_VENDOR_TEMPLATE_START = 0x40000000
  1698. } camera3_request_template_t;
  1699. /**
  1700. * camera3_capture_request_t:
  1701. *
  1702. * A single request for image capture/buffer reprocessing, sent to the Camera
  1703. * HAL device by the framework in process_capture_request().
  1704. *
  1705. * The request contains the settings to be used for this capture, and the set of
  1706. * output buffers to write the resulting image data in. It may optionally
  1707. * contain an input buffer, in which case the request is for reprocessing that
  1708. * input buffer instead of capturing a new image with the camera sensor. The
  1709. * capture is identified by the frame_number.
  1710. *
  1711. * In response, the camera HAL device must send a camera3_capture_result
  1712. * structure asynchronously to the framework, using the process_capture_result()
  1713. * callback.
  1714. */
  1715. typedef struct camera3_capture_request {
  1716. /**
  1717. * The frame number is an incrementing integer set by the framework to
  1718. * uniquely identify this capture. It needs to be returned in the result
  1719. * call, and is also used to identify the request in asynchronous
  1720. * notifications sent to camera3_callback_ops_t.notify().
  1721. */
  1722. uint32_t frame_number;
  1723. /**
  1724. * The settings buffer contains the capture and processing parameters for
  1725. * the request. As a special case, a NULL settings buffer indicates that the
  1726. * settings are identical to the most-recently submitted capture request. A
  1727. * NULL buffer cannot be used as the first submitted request after a
  1728. * configure_streams() call.
  1729. */
  1730. const camera_metadata_t *settings;
  1731. /**
  1732. * The input stream buffer to use for this request, if any.
  1733. *
  1734. * If input_buffer is NULL, then the request is for a new capture from the
  1735. * imager. If input_buffer is valid, the request is for reprocessing the
  1736. * image contained in input_buffer.
  1737. *
  1738. * In the latter case, the HAL must set the release_fence of the
  1739. * input_buffer to a valid sync fence, or to -1 if the HAL does not support
  1740. * sync, before process_capture_request() returns.
  1741. *
  1742. * The HAL is required to wait on the acquire sync fence of the input buffer
  1743. * before accessing it.
  1744. *
  1745. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1746. *
  1747. * Any input buffer included here will have been registered with the HAL
  1748. * through register_stream_buffers() before its inclusion in a request.
  1749. *
  1750. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1751. *
  1752. * The buffers will not have been pre-registered with the HAL.
  1753. * Subsequent requests may reuse buffers, or provide entirely new buffers.
  1754. */
  1755. camera3_stream_buffer_t *input_buffer;
  1756. /**
  1757. * The number of output buffers for this capture request. Must be at least
  1758. * 1.
  1759. */
  1760. uint32_t num_output_buffers;
  1761. /**
  1762. * An array of num_output_buffers stream buffers, to be filled with image
  1763. * data from this capture/reprocess. The HAL must wait on the acquire fences
  1764. * of each stream buffer before writing to them.
  1765. *
  1766. * The HAL takes ownership of the actual buffer_handle_t entries in
  1767. * output_buffers; the framework does not access them until they are
  1768. * returned in a camera3_capture_result_t.
  1769. *
  1770. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1771. *
  1772. * All the buffers included here will have been registered with the HAL
  1773. * through register_stream_buffers() before their inclusion in a request.
  1774. *
  1775. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1776. *
  1777. * Any or all of the buffers included here may be brand new in this
  1778. * request (having never before seen by the HAL).
  1779. */
  1780. const camera3_stream_buffer_t *output_buffers;
  1781. } camera3_capture_request_t;
  1782. /**
  1783. * camera3_capture_result_t:
  1784. *
  1785. * The result of a single capture/reprocess by the camera HAL device. This is
  1786. * sent to the framework asynchronously with process_capture_result(), in
  1787. * response to a single capture request sent to the HAL with
  1788. * process_capture_request(). Multiple process_capture_result() calls may be
  1789. * performed by the HAL for each request.
  1790. *
  1791. * Each call, all with the same frame
  1792. * number, may contain some subset of the output buffers, and/or the result
  1793. * metadata. The metadata may only be provided once for a given frame number;
  1794. * all other calls must set the result metadata to NULL.
  1795. *
  1796. * The result structure contains the output metadata from this capture, and the
  1797. * set of output buffers that have been/will be filled for this capture. Each
  1798. * output buffer may come with a release sync fence that the framework will wait
  1799. * on before reading, in case the buffer has not yet been filled by the HAL.
  1800. *
  1801. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1802. *
  1803. * The metadata may be provided multiple times for a single frame number. The
  1804. * framework will accumulate together the final result set by combining each
  1805. * partial result together into the total result set.
  1806. *
  1807. * If an input buffer is given in a request, the HAL must return it in one of
  1808. * the process_capture_result calls, and the call may be to just return the input
  1809. * buffer, without metadata and output buffers; the sync fences must be handled
  1810. * the same way they are done for output buffers.
  1811. *
  1812. *
  1813. * Performance considerations:
  1814. *
  1815. * Applications will also receive these partial results immediately, so sending
  1816. * partial results is a highly recommended performance optimization to avoid
  1817. * the total pipeline latency before sending the results for what is known very
  1818. * early on in the pipeline.
  1819. *
  1820. * A typical use case might be calculating the AF state halfway through the
  1821. * pipeline; by sending the state back to the framework immediately, we get a
  1822. * 50% performance increase and perceived responsiveness of the auto-focus.
  1823. *
  1824. */
  1825. typedef struct camera3_capture_result {
  1826. /**
  1827. * The frame number is an incrementing integer set by the framework in the
  1828. * submitted request to uniquely identify this capture. It is also used to
  1829. * identify the request in asynchronous notifications sent to
  1830. * camera3_callback_ops_t.notify().
  1831. */
  1832. uint32_t frame_number;
  1833. /**
  1834. * The result metadata for this capture. This contains information about the
  1835. * final capture parameters, the state of the capture and post-processing
  1836. * hardware, the state of the 3A algorithms, if enabled, and the output of
  1837. * any enabled statistics units.
  1838. *
  1839. * Only one call to process_capture_result() with a given frame_number may
  1840. * include the result metadata. All other calls for the same frame_number
  1841. * must set this to NULL.
  1842. *
  1843. * If there was an error producing the result metadata, result must be an
  1844. * empty metadata buffer, and notify() must be called with ERROR_RESULT.
  1845. *
  1846. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1847. *
  1848. * Multiple calls to process_capture_result() with a given frame_number
  1849. * may include the result metadata.
  1850. *
  1851. * Partial metadata submitted should not include any metadata key returned
  1852. * in a previous partial result for a given frame. Each new partial result
  1853. * for that frame must also set a distinct partial_result value.
  1854. *
  1855. * If notify has been called with ERROR_RESULT, all further partial
  1856. * results for that frame are ignored by the framework.
  1857. */
  1858. const camera_metadata_t *result;
  1859. /**
  1860. * The number of output buffers returned in this result structure. Must be
  1861. * less than or equal to the matching capture request's count. If this is
  1862. * less than the buffer count in the capture request, at least one more call
  1863. * to process_capture_result with the same frame_number must be made, to
  1864. * return the remaining output buffers to the framework. This may only be
  1865. * zero if the structure includes valid result metadata or an input buffer
  1866. * is returned in this result.
  1867. */
  1868. uint32_t num_output_buffers;
  1869. /**
  1870. * The handles for the output stream buffers for this capture. They may not
  1871. * yet be filled at the time the HAL calls process_capture_result(); the
  1872. * framework will wait on the release sync fences provided by the HAL before
  1873. * reading the buffers.
  1874. *
  1875. * The HAL must set the stream buffer's release sync fence to a valid sync
  1876. * fd, or to -1 if the buffer has already been filled.
  1877. *
  1878. * If the HAL encounters an error while processing the buffer, and the
  1879. * buffer is not filled, the buffer's status field must be set to
  1880. * CAMERA3_BUFFER_STATUS_ERROR. If the HAL did not wait on the acquire fence
  1881. * before encountering the error, the acquire fence should be copied into
  1882. * the release fence, to allow the framework to wait on the fence before
  1883. * reusing the buffer.
  1884. *
  1885. * The acquire fence must be set to -1 for all output buffers. If
  1886. * num_output_buffers is zero, this may be NULL. In that case, at least one
  1887. * more process_capture_result call must be made by the HAL to provide the
  1888. * output buffers.
  1889. *
  1890. * When process_capture_result is called with a new buffer for a frame,
  1891. * all previous frames' buffers for that corresponding stream must have been
  1892. * already delivered (the fences need not have yet been signaled).
  1893. *
  1894. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1895. *
  1896. * Gralloc buffers for a frame may be sent to framework before the
  1897. * corresponding SHUTTER-notify.
  1898. *
  1899. * Performance considerations:
  1900. *
  1901. * Buffers delivered to the framework will not be dispatched to the
  1902. * application layer until a start of exposure timestamp has been received
  1903. * via a SHUTTER notify() call. It is highly recommended to
  1904. * dispatch that call as early as possible.
  1905. */
  1906. const camera3_stream_buffer_t *output_buffers;
  1907. /**
  1908. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1909. *
  1910. * The handle for the input stream buffer for this capture. It may not
  1911. * yet be consumed at the time the HAL calls process_capture_result(); the
  1912. * framework will wait on the release sync fences provided by the HAL before
  1913. * reusing the buffer.
  1914. *
  1915. * The HAL should handle the sync fences the same way they are done for
  1916. * output_buffers.
  1917. *
  1918. * Only one input buffer is allowed to be sent per request. Similarly to
  1919. * output buffers, the ordering of returned input buffers must be
  1920. * maintained by the HAL.
  1921. *
  1922. * Performance considerations:
  1923. *
  1924. * The input buffer should be returned as early as possible. If the HAL
  1925. * supports sync fences, it can call process_capture_result to hand it back
  1926. * with sync fences being set appropriately. If the sync fences are not
  1927. * supported, the buffer can only be returned when it is consumed, which
  1928. * may take long time; the HAL may choose to copy this input buffer to make
  1929. * the buffer return sooner.
  1930. */
  1931. const camera3_stream_buffer_t *input_buffer;
  1932. /**
  1933. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1934. *
  1935. * In order to take advantage of partial results, the HAL must set the
  1936. * static metadata android.request.partialResultCount to the number of
  1937. * partial results it will send for each frame.
  1938. *
  1939. * Each new capture result with a partial result must set
  1940. * this field (partial_result) to a distinct inclusive value between
  1941. * 1 and android.request.partialResultCount.
  1942. *
  1943. * HALs not wishing to take advantage of this feature must not
  1944. * set an android.request.partialResultCount or partial_result to a value
  1945. * other than 1.
  1946. *
  1947. * This value must be set to 0 when a capture result contains buffers only
  1948. * and no metadata.
  1949. */
  1950. uint32_t partial_result;
  1951. } camera3_capture_result_t;
  1952. /**********************************************************************
  1953. *
  1954. * Callback methods for the HAL to call into the framework.
  1955. *
  1956. * These methods are used to return metadata and image buffers for a completed
  1957. * or failed captures, and to notify the framework of asynchronous events such
  1958. * as errors.
  1959. *
  1960. * The framework will not call back into the HAL from within these callbacks,
  1961. * and these calls will not block for extended periods.
  1962. *
  1963. */
  1964. typedef struct camera3_callback_ops {
  1965. /**
  1966. * process_capture_result:
  1967. *
  1968. * Send results from a completed capture to the framework.
  1969. * process_capture_result() may be invoked multiple times by the HAL in
  1970. * response to a single capture request. This allows, for example, the
  1971. * metadata and low-resolution buffers to be returned in one call, and
  1972. * post-processed JPEG buffers in a later call, once it is available. Each
  1973. * call must include the frame number of the request it is returning
  1974. * metadata or buffers for.
  1975. *
  1976. * A component (buffer or metadata) of the complete result may only be
  1977. * included in one process_capture_result call. A buffer for each stream,
  1978. * and the result metadata, must be returned by the HAL for each request in
  1979. * one of the process_capture_result calls, even in case of errors producing
  1980. * some of the output. A call to process_capture_result() with neither
  1981. * output buffers or result metadata is not allowed.
  1982. *
  1983. * The order of returning metadata and buffers for a single result does not
  1984. * matter, but buffers for a given stream must be returned in FIFO order. So
  1985. * the buffer for request 5 for stream A must always be returned before the
  1986. * buffer for request 6 for stream A. This also applies to the result
  1987. * metadata; the metadata for request 5 must be returned before the metadata
  1988. * for request 6.
  1989. *
  1990. * However, different streams are independent of each other, so it is
  1991. * acceptable and expected that the buffer for request 5 for stream A may be
  1992. * returned after the buffer for request 6 for stream B is. And it is
  1993. * acceptable that the result metadata for request 6 for stream B is
  1994. * returned before the buffer for request 5 for stream A is.
  1995. *
  1996. * The HAL retains ownership of result structure, which only needs to be
  1997. * valid to access during this call. The framework will copy whatever it
  1998. * needs before this call returns.
  1999. *
  2000. * The output buffers do not need to be filled yet; the framework will wait
  2001. * on the stream buffer release sync fence before reading the buffer
  2002. * data. Therefore, this method should be called by the HAL as soon as
  2003. * possible, even if some or all of the output buffers are still in
  2004. * being filled. The HAL must include valid release sync fences into each
  2005. * output_buffers stream buffer entry, or -1 if that stream buffer is
  2006. * already filled.
  2007. *
  2008. * If the result buffer cannot be constructed for a request, the HAL should
  2009. * return an empty metadata buffer, but still provide the output buffers and
  2010. * their sync fences. In addition, notify() must be called with an
  2011. * ERROR_RESULT message.
  2012. *
  2013. * If an output buffer cannot be filled, its status field must be set to
  2014. * STATUS_ERROR. In addition, notify() must be called with a ERROR_BUFFER
  2015. * message.
  2016. *
  2017. * If the entire capture has failed, then this method still needs to be
  2018. * called to return the output buffers to the framework. All the buffer
  2019. * statuses should be STATUS_ERROR, and the result metadata should be an
  2020. * empty buffer. In addition, notify() must be called with a ERROR_REQUEST
  2021. * message. In this case, individual ERROR_RESULT/ERROR_BUFFER messages
  2022. * should not be sent.
  2023. *
  2024. * Performance requirements:
  2025. *
  2026. * This is a non-blocking call. The framework will return this call in 5ms.
  2027. *
  2028. * The pipeline latency (see S7 for definition) should be less than or equal to
  2029. * 4 frame intervals, and must be less than or equal to 8 frame intervals.
  2030. *
  2031. */
  2032. void (*process_capture_result)(const struct camera3_callback_ops *,
  2033. const camera3_capture_result_t *result);
  2034. /**
  2035. * notify:
  2036. *
  2037. * Asynchronous notification callback from the HAL, fired for various
  2038. * reasons. Only for information independent of frame capture, or that
  2039. * require specific timing. The ownership of the message structure remains
  2040. * with the HAL, and the msg only needs to be valid for the duration of this
  2041. * call.
  2042. *
  2043. * Multiple threads may call notify() simultaneously.
  2044. *
  2045. * <= CAMERA_DEVICE_API_VERSION_3_1:
  2046. *
  2047. * The notification for the start of exposure for a given request must be
  2048. * sent by the HAL before the first call to process_capture_result() for
  2049. * that request is made.
  2050. *
  2051. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2052. *
  2053. * Buffers delivered to the framework will not be dispatched to the
  2054. * application layer until a start of exposure timestamp has been received
  2055. * via a SHUTTER notify() call. It is highly recommended to
  2056. * dispatch this call as early as possible.
  2057. *
  2058. * ------------------------------------------------------------------------
  2059. * Performance requirements:
  2060. *
  2061. * This is a non-blocking call. The framework will return this call in 5ms.
  2062. */
  2063. void (*notify)(const struct camera3_callback_ops *,
  2064. const camera3_notify_msg_t *msg);
  2065. } camera3_callback_ops_t;
  2066. /**********************************************************************
  2067. *
  2068. * Camera device operations
  2069. *
  2070. */
  2071. typedef struct camera3_device_ops {
  2072. /**
  2073. * initialize:
  2074. *
  2075. * One-time initialization to pass framework callback function pointers to
  2076. * the HAL. Will be called once after a successful open() call, before any
  2077. * other functions are called on the camera3_device_ops structure.
  2078. *
  2079. * Performance requirements:
  2080. *
  2081. * This should be a non-blocking call. The HAL should return from this call
  2082. * in 5ms, and must return from this call in 10ms.
  2083. *
  2084. * Return values:
  2085. *
  2086. * 0: On successful initialization
  2087. *
  2088. * -ENODEV: If initialization fails. Only close() can be called successfully
  2089. * by the framework after this.
  2090. */
  2091. int (*initialize)(const struct camera3_device *,
  2092. const camera3_callback_ops_t *callback_ops);
  2093. /**********************************************************************
  2094. * Stream management
  2095. */
  2096. /**
  2097. * configure_streams:
  2098. *
  2099. * CAMERA_DEVICE_API_VERSION_3_0 only:
  2100. *
  2101. * Reset the HAL camera device processing pipeline and set up new input and
  2102. * output streams. This call replaces any existing stream configuration with
  2103. * the streams defined in the stream_list. This method will be called at
  2104. * least once after initialize() before a request is submitted with
  2105. * process_capture_request().
  2106. *
  2107. * The stream_list must contain at least one output-capable stream, and may
  2108. * not contain more than one input-capable stream.
  2109. *
  2110. * The stream_list may contain streams that are also in the currently-active
  2111. * set of streams (from the previous call to configure_stream()). These
  2112. * streams will already have valid values for usage, max_buffers, and the
  2113. * private pointer.
  2114. *
  2115. * If such a stream has already had its buffers registered,
  2116. * register_stream_buffers() will not be called again for the stream, and
  2117. * buffers from the stream can be immediately included in input requests.
  2118. *
  2119. * If the HAL needs to change the stream configuration for an existing
  2120. * stream due to the new configuration, it may rewrite the values of usage
  2121. * and/or max_buffers during the configure call.
  2122. *
  2123. * The framework will detect such a change, and will then reallocate the
  2124. * stream buffers, and call register_stream_buffers() again before using
  2125. * buffers from that stream in a request.
  2126. *
  2127. * If a currently-active stream is not included in stream_list, the HAL may
  2128. * safely remove any references to that stream. It will not be reused in a
  2129. * later configure() call by the framework, and all the gralloc buffers for
  2130. * it will be freed after the configure_streams() call returns.
  2131. *
  2132. * The stream_list structure is owned by the framework, and may not be
  2133. * accessed once this call completes. The address of an individual
  2134. * camera3_stream_t structure will remain valid for access by the HAL until
  2135. * the end of the first configure_stream() call which no longer includes
  2136. * that camera3_stream_t in the stream_list argument. The HAL may not change
  2137. * values in the stream structure outside of the private pointer, except for
  2138. * the usage and max_buffers members during the configure_streams() call
  2139. * itself.
  2140. *
  2141. * If the stream is new, the usage, max_buffer, and private pointer fields
  2142. * of the stream structure will all be set to 0. The HAL device must set
  2143. * these fields before the configure_streams() call returns. These fields
  2144. * are then used by the framework and the platform gralloc module to
  2145. * allocate the gralloc buffers for each stream.
  2146. *
  2147. * Before such a new stream can have its buffers included in a capture
  2148. * request, the framework will call register_stream_buffers() with that
  2149. * stream. However, the framework is not required to register buffers for
  2150. * _all_ streams before submitting a request. This allows for quick startup
  2151. * of (for example) a preview stream, with allocation for other streams
  2152. * happening later or concurrently.
  2153. *
  2154. * ------------------------------------------------------------------------
  2155. * CAMERA_DEVICE_API_VERSION_3_1 only:
  2156. *
  2157. * Reset the HAL camera device processing pipeline and set up new input and
  2158. * output streams. This call replaces any existing stream configuration with
  2159. * the streams defined in the stream_list. This method will be called at
  2160. * least once after initialize() before a request is submitted with
  2161. * process_capture_request().
  2162. *
  2163. * The stream_list must contain at least one output-capable stream, and may
  2164. * not contain more than one input-capable stream.
  2165. *
  2166. * The stream_list may contain streams that are also in the currently-active
  2167. * set of streams (from the previous call to configure_stream()). These
  2168. * streams will already have valid values for usage, max_buffers, and the
  2169. * private pointer.
  2170. *
  2171. * If such a stream has already had its buffers registered,
  2172. * register_stream_buffers() will not be called again for the stream, and
  2173. * buffers from the stream can be immediately included in input requests.
  2174. *
  2175. * If the HAL needs to change the stream configuration for an existing
  2176. * stream due to the new configuration, it may rewrite the values of usage
  2177. * and/or max_buffers during the configure call.
  2178. *
  2179. * The framework will detect such a change, and will then reallocate the
  2180. * stream buffers, and call register_stream_buffers() again before using
  2181. * buffers from that stream in a request.
  2182. *
  2183. * If a currently-active stream is not included in stream_list, the HAL may
  2184. * safely remove any references to that stream. It will not be reused in a
  2185. * later configure() call by the framework, and all the gralloc buffers for
  2186. * it will be freed after the configure_streams() call returns.
  2187. *
  2188. * The stream_list structure is owned by the framework, and may not be
  2189. * accessed once this call completes. The address of an individual
  2190. * camera3_stream_t structure will remain valid for access by the HAL until
  2191. * the end of the first configure_stream() call which no longer includes
  2192. * that camera3_stream_t in the stream_list argument. The HAL may not change
  2193. * values in the stream structure outside of the private pointer, except for
  2194. * the usage and max_buffers members during the configure_streams() call
  2195. * itself.
  2196. *
  2197. * If the stream is new, max_buffer, and private pointer fields of the
  2198. * stream structure will all be set to 0. The usage will be set to the
  2199. * consumer usage flags. The HAL device must set these fields before the
  2200. * configure_streams() call returns. These fields are then used by the
  2201. * framework and the platform gralloc module to allocate the gralloc
  2202. * buffers for each stream.
  2203. *
  2204. * Before such a new stream can have its buffers included in a capture
  2205. * request, the framework will call register_stream_buffers() with that
  2206. * stream. However, the framework is not required to register buffers for
  2207. * _all_ streams before submitting a request. This allows for quick startup
  2208. * of (for example) a preview stream, with allocation for other streams
  2209. * happening later or concurrently.
  2210. *
  2211. * ------------------------------------------------------------------------
  2212. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2213. *
  2214. * Reset the HAL camera device processing pipeline and set up new input and
  2215. * output streams. This call replaces any existing stream configuration with
  2216. * the streams defined in the stream_list. This method will be called at
  2217. * least once after initialize() before a request is submitted with
  2218. * process_capture_request().
  2219. *
  2220. * The stream_list must contain at least one output-capable stream, and may
  2221. * not contain more than one input-capable stream.
  2222. *
  2223. * The stream_list may contain streams that are also in the currently-active
  2224. * set of streams (from the previous call to configure_stream()). These
  2225. * streams will already have valid values for usage, max_buffers, and the
  2226. * private pointer.
  2227. *
  2228. * If the HAL needs to change the stream configuration for an existing
  2229. * stream due to the new configuration, it may rewrite the values of usage
  2230. * and/or max_buffers during the configure call.
  2231. *
  2232. * The framework will detect such a change, and may then reallocate the
  2233. * stream buffers before using buffers from that stream in a request.
  2234. *
  2235. * If a currently-active stream is not included in stream_list, the HAL may
  2236. * safely remove any references to that stream. It will not be reused in a
  2237. * later configure() call by the framework, and all the gralloc buffers for
  2238. * it will be freed after the configure_streams() call returns.
  2239. *
  2240. * The stream_list structure is owned by the framework, and may not be
  2241. * accessed once this call completes. The address of an individual
  2242. * camera3_stream_t structure will remain valid for access by the HAL until
  2243. * the end of the first configure_stream() call which no longer includes
  2244. * that camera3_stream_t in the stream_list argument. The HAL may not change
  2245. * values in the stream structure outside of the private pointer, except for
  2246. * the usage and max_buffers members during the configure_streams() call
  2247. * itself.
  2248. *
  2249. * If the stream is new, max_buffer, and private pointer fields of the
  2250. * stream structure will all be set to 0. The usage will be set to the
  2251. * consumer usage flags. The HAL device must set these fields before the
  2252. * configure_streams() call returns. These fields are then used by the
  2253. * framework and the platform gralloc module to allocate the gralloc
  2254. * buffers for each stream.
  2255. *
  2256. * Newly allocated buffers may be included in a capture request at any time
  2257. * by the framework. Once a gralloc buffer is returned to the framework
  2258. * with process_capture_result (and its respective release_fence has been
  2259. * signaled) the framework may free or reuse it at any time.
  2260. *
  2261. * ------------------------------------------------------------------------
  2262. *
  2263. * Preconditions:
  2264. *
  2265. * The framework will only call this method when no captures are being
  2266. * processed. That is, all results have been returned to the framework, and
  2267. * all in-flight input and output buffers have been returned and their
  2268. * release sync fences have been signaled by the HAL. The framework will not
  2269. * submit new requests for capture while the configure_streams() call is
  2270. * underway.
  2271. *
  2272. * Postconditions:
  2273. *
  2274. * The HAL device must configure itself to provide maximum possible output
  2275. * frame rate given the sizes and formats of the output streams, as
  2276. * documented in the camera device's static metadata.
  2277. *
  2278. * Performance requirements:
  2279. *
  2280. * This call is expected to be heavyweight and possibly take several hundred
  2281. * milliseconds to complete, since it may require resetting and
  2282. * reconfiguring the image sensor and the camera processing pipeline.
  2283. * Nevertheless, the HAL device should attempt to minimize the
  2284. * reconfiguration delay to minimize the user-visible pauses during
  2285. * application operational mode changes (such as switching from still
  2286. * capture to video recording).
  2287. *
  2288. * The HAL should return from this call in 500ms, and must return from this
  2289. * call in 1000ms.
  2290. *
  2291. * Return values:
  2292. *
  2293. * 0: On successful stream configuration
  2294. *
  2295. * -EINVAL: If the requested stream configuration is invalid. Some examples
  2296. * of invalid stream configurations include:
  2297. *
  2298. * - Including more than 1 input-capable stream (INPUT or
  2299. * BIDIRECTIONAL)
  2300. *
  2301. * - Not including any output-capable streams (OUTPUT or
  2302. * BIDIRECTIONAL)
  2303. *
  2304. * - Including streams with unsupported formats, or an unsupported
  2305. * size for that format.
  2306. *
  2307. * - Including too many output streams of a certain format.
  2308. *
  2309. * Note that the framework submitting an invalid stream
  2310. * configuration is not normal operation, since stream
  2311. * configurations are checked before configure. An invalid
  2312. * configuration means that a bug exists in the framework code, or
  2313. * there is a mismatch between the HAL's static metadata and the
  2314. * requirements on streams.
  2315. *
  2316. * -ENODEV: If there has been a fatal error and the device is no longer
  2317. * operational. Only close() can be called successfully by the
  2318. * framework after this error is returned.
  2319. */
  2320. int (*configure_streams)(const struct camera3_device *,
  2321. camera3_stream_configuration_t *stream_list);
  2322. /**
  2323. * register_stream_buffers:
  2324. *
  2325. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2326. *
  2327. * DEPRECATED. This will not be called and must be set to NULL.
  2328. *
  2329. * <= CAMERA_DEVICE_API_VERSION_3_1:
  2330. *
  2331. * Register buffers for a given stream with the HAL device. This method is
  2332. * called by the framework after a new stream is defined by
  2333. * configure_streams, and before buffers from that stream are included in a
  2334. * capture request. If the same stream is listed in a subsequent
  2335. * configure_streams() call, register_stream_buffers will _not_ be called
  2336. * again for that stream.
  2337. *
  2338. * The framework does not need to register buffers for all configured
  2339. * streams before it submits the first capture request. This allows quick
  2340. * startup for preview (or similar use cases) while other streams are still
  2341. * being allocated.
  2342. *
  2343. * This method is intended to allow the HAL device to map or otherwise
  2344. * prepare the buffers for later use. The buffers passed in will already be
  2345. * locked for use. At the end of the call, all the buffers must be ready to
  2346. * be returned to the stream. The buffer_set argument is only valid for the
  2347. * duration of this call.
  2348. *
  2349. * If the stream format was set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,
  2350. * the camera HAL should inspect the passed-in buffers here to determine any
  2351. * platform-private pixel format information.
  2352. *
  2353. * Performance requirements:
  2354. *
  2355. * This should be a non-blocking call. The HAL should return from this call
  2356. * in 1ms, and must return from this call in 5ms.
  2357. *
  2358. * Return values:
  2359. *
  2360. * 0: On successful registration of the new stream buffers
  2361. *
  2362. * -EINVAL: If the stream_buffer_set does not refer to a valid active
  2363. * stream, or if the buffers array is invalid.
  2364. *
  2365. * -ENOMEM: If there was a failure in registering the buffers. The framework
  2366. * must consider all the stream buffers to be unregistered, and can
  2367. * try to register again later.
  2368. *
  2369. * -ENODEV: If there is a fatal error, and the device is no longer
  2370. * operational. Only close() can be called successfully by the
  2371. * framework after this error is returned.
  2372. */
  2373. int (*register_stream_buffers)(const struct camera3_device *,
  2374. const camera3_stream_buffer_set_t *buffer_set);
  2375. /**********************************************************************
  2376. * Request creation and submission
  2377. */
  2378. /**
  2379. * construct_default_request_settings:
  2380. *
  2381. * Create capture settings for standard camera use cases.
  2382. *
  2383. * The device must return a settings buffer that is configured to meet the
  2384. * requested use case, which must be one of the CAMERA3_TEMPLATE_*
  2385. * enums. All request control fields must be included.
  2386. *
  2387. * The HAL retains ownership of this structure, but the pointer to the
  2388. * structure must be valid until the device is closed. The framework and the
  2389. * HAL may not modify the buffer once it is returned by this call. The same
  2390. * buffer may be returned for subsequent calls for the same template, or for
  2391. * other templates.
  2392. *
  2393. * Performance requirements:
  2394. *
  2395. * This should be a non-blocking call. The HAL should return from this call
  2396. * in 1ms, and must return from this call in 5ms.
  2397. *
  2398. * Return values:
  2399. *
  2400. * Valid metadata: On successful creation of a default settings
  2401. * buffer.
  2402. *
  2403. * NULL: In case of a fatal error. After this is returned, only
  2404. * the close() method can be called successfully by the
  2405. * framework.
  2406. */
  2407. const camera_metadata_t* (*construct_default_request_settings)(
  2408. const struct camera3_device *,
  2409. int type);
  2410. /**
  2411. * process_capture_request:
  2412. *
  2413. * Send a new capture request to the HAL. The HAL should not return from
  2414. * this call until it is ready to accept the next request to process. Only
  2415. * one call to process_capture_request() will be made at a time by the
  2416. * framework, and the calls will all be from the same thread. The next call
  2417. * to process_capture_request() will be made as soon as a new request and
  2418. * its associated buffers are available. In a normal preview scenario, this
  2419. * means the function will be called again by the framework almost
  2420. * instantly.
  2421. *
  2422. * The actual request processing is asynchronous, with the results of
  2423. * capture being returned by the HAL through the process_capture_result()
  2424. * call. This call requires the result metadata to be available, but output
  2425. * buffers may simply provide sync fences to wait on. Multiple requests are
  2426. * expected to be in flight at once, to maintain full output frame rate.
  2427. *
  2428. * The framework retains ownership of the request structure. It is only
  2429. * guaranteed to be valid during this call. The HAL device must make copies
  2430. * of the information it needs to retain for the capture processing. The HAL
  2431. * is responsible for waiting on and closing the buffers' fences and
  2432. * returning the buffer handles to the framework.
  2433. *
  2434. * The HAL must write the file descriptor for the input buffer's release
  2435. * sync fence into input_buffer->release_fence, if input_buffer is not
  2436. * NULL. If the HAL returns -1 for the input buffer release sync fence, the
  2437. * framework is free to immediately reuse the input buffer. Otherwise, the
  2438. * framework will wait on the sync fence before refilling and reusing the
  2439. * input buffer.
  2440. *
  2441. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2442. *
  2443. * The input/output buffers provided by the framework in each request
  2444. * may be brand new (having never before seen by the HAL).
  2445. *
  2446. * ------------------------------------------------------------------------
  2447. * Performance considerations:
  2448. *
  2449. * Handling a new buffer should be extremely lightweight and there should be
  2450. * no frame rate degradation or frame jitter introduced.
  2451. *
  2452. * This call must return fast enough to ensure that the requested frame
  2453. * rate can be sustained, especially for streaming cases (post-processing
  2454. * quality settings set to FAST). The HAL should return this call in 1
  2455. * frame interval, and must return from this call in 4 frame intervals.
  2456. *
  2457. * Return values:
  2458. *
  2459. * 0: On a successful start to processing the capture request
  2460. *
  2461. * -EINVAL: If the input is malformed (the settings are NULL when not
  2462. * allowed, there are 0 output buffers, etc) and capture processing
  2463. * cannot start. Failures during request processing should be
  2464. * handled by calling camera3_callback_ops_t.notify(). In case of
  2465. * this error, the framework will retain responsibility for the
  2466. * stream buffers' fences and the buffer handles; the HAL should
  2467. * not close the fences or return these buffers with
  2468. * process_capture_result.
  2469. *
  2470. * -ENODEV: If the camera device has encountered a serious error. After this
  2471. * error is returned, only the close() method can be successfully
  2472. * called by the framework.
  2473. *
  2474. */
  2475. int (*process_capture_request)(const struct camera3_device *,
  2476. camera3_capture_request_t *request);
  2477. /**********************************************************************
  2478. * Miscellaneous methods
  2479. */
  2480. /**
  2481. * get_metadata_vendor_tag_ops:
  2482. *
  2483. * Get methods to query for vendor extension metadata tag information. The
  2484. * HAL should fill in all the vendor tag operation methods, or leave ops
  2485. * unchanged if no vendor tags are defined.
  2486. *
  2487. * The definition of vendor_tag_query_ops_t can be found in
  2488. * system/media/camera/include/system/camera_metadata.h.
  2489. *
  2490. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2491. * DEPRECATED. This function has been deprecated and should be set to
  2492. * NULL by the HAL. Please implement get_vendor_tag_ops in camera_common.h
  2493. * instead.
  2494. */
  2495. void (*get_metadata_vendor_tag_ops)(const struct camera3_device*,
  2496. vendor_tag_query_ops_t* ops);
  2497. /**
  2498. * dump:
  2499. *
  2500. * Print out debugging state for the camera device. This will be called by
  2501. * the framework when the camera service is asked for a debug dump, which
  2502. * happens when using the dumpsys tool, or when capturing a bugreport.
  2503. *
  2504. * The passed-in file descriptor can be used to write debugging text using
  2505. * dprintf() or write(). The text should be in ASCII encoding only.
  2506. *
  2507. * Performance requirements:
  2508. *
  2509. * This must be a non-blocking call. The HAL should return from this call
  2510. * in 1ms, must return from this call in 10ms. This call must avoid
  2511. * deadlocks, as it may be called at any point during camera operation.
  2512. * Any synchronization primitives used (such as mutex locks or semaphores)
  2513. * should be acquired with a timeout.
  2514. */
  2515. void (*dump)(const struct camera3_device *, int fd);
  2516. /**
  2517. * flush:
  2518. *
  2519. * Flush all currently in-process captures and all buffers in the pipeline
  2520. * on the given device. The framework will use this to dump all state as
  2521. * quickly as possible in order to prepare for a configure_streams() call.
  2522. *
  2523. * No buffers are required to be successfully returned, so every buffer
  2524. * held at the time of flush() (whether successfully filled or not) may be
  2525. * returned with CAMERA3_BUFFER_STATUS_ERROR. Note the HAL is still allowed
  2526. * to return valid (CAMERA3_BUFFER_STATUS_OK) buffers during this call,
  2527. * provided they are successfully filled.
  2528. *
  2529. * All requests currently in the HAL are expected to be returned as soon as
  2530. * possible. Not-in-process requests should return errors immediately. Any
  2531. * interruptible hardware blocks should be stopped, and any uninterruptible
  2532. * blocks should be waited on.
  2533. *
  2534. * More specifically, the HAL must follow below requirements for various cases:
  2535. *
  2536. * 1. For captures that are too late for the HAL to cancel/stop, and will be
  2537. * completed normally by the HAL; i.e. the HAL can send shutter/notify and
  2538. * process_capture_result and buffers as normal.
  2539. *
  2540. * 2. For pending requests that have not done any processing, the HAL must call notify
  2541. * CAMERA3_MSG_ERROR_REQUEST, and return all the output buffers with
  2542. * process_capture_result in the error state (CAMERA3_BUFFER_STATUS_ERROR).
  2543. * The HAL must not place the release fence into an error state, instead,
  2544. * the release fences must be set to the acquire fences passed by the framework,
  2545. * or -1 if they have been waited on by the HAL already. This is also the path
  2546. * to follow for any captures for which the HAL already called notify() with
  2547. * CAMERA3_MSG_SHUTTER but won't be producing any metadata/valid buffers for.
  2548. * After CAMERA3_MSG_ERROR_REQUEST, for a given frame, only process_capture_results with
  2549. * buffers in CAMERA3_BUFFER_STATUS_ERROR are allowed. No further notifys or
  2550. * process_capture_result with non-null metadata is allowed.
  2551. *
  2552. * 3. For partially completed pending requests that will not have all the output
  2553. * buffers or perhaps missing metadata, the HAL should follow below:
  2554. *
  2555. * 3.1. Call notify with CAMERA3_MSG_ERROR_RESULT if some of the expected result
  2556. * metadata (i.e. one or more partial metadata) won't be available for the capture.
  2557. *
  2558. * 3.2. Call notify with CAMERA3_MSG_ERROR_BUFFER for every buffer that won't
  2559. * be produced for the capture.
  2560. *
  2561. * 3.3 Call notify with CAMERA3_MSG_SHUTTER with the capture timestamp before
  2562. * any buffers/metadata are returned with process_capture_result.
  2563. *
  2564. * 3.4 For captures that will produce some results, the HAL must not call
  2565. * CAMERA3_MSG_ERROR_REQUEST, since that indicates complete failure.
  2566. *
  2567. * 3.5. Valid buffers/metadata should be passed to the framework as normal.
  2568. *
  2569. * 3.6. Failed buffers should be returned to the framework as described for case 2.
  2570. * But failed buffers do not have to follow the strict ordering valid buffers do,
  2571. * and may be out-of-order with respect to valid buffers. For example, if buffers
  2572. * A, B, C, D, E are sent, D and E are failed, then A, E, B, D, C is an acceptable
  2573. * return order.
  2574. *
  2575. * 3.7. For fully-missing metadata, calling CAMERA3_MSG_ERROR_RESULT is sufficient, no
  2576. * need to call process_capture_result with NULL metadata or equivalent.
  2577. *
  2578. * flush() should only return when there are no more outstanding buffers or
  2579. * requests left in the HAL. The framework may call configure_streams (as
  2580. * the HAL state is now quiesced) or may issue new requests.
  2581. *
  2582. * Note that it's sufficient to only support fully-succeeded and fully-failed result cases.
  2583. * However, it is highly desirable to support the partial failure cases as well, as it
  2584. * could help improve the flush call overall performance.
  2585. *
  2586. * Performance requirements:
  2587. *
  2588. * The HAL should return from this call in 100ms, and must return from this
  2589. * call in 1000ms. And this call must not be blocked longer than pipeline
  2590. * latency (see S7 for definition).
  2591. *
  2592. * Version information:
  2593. *
  2594. * only available if device version >= CAMERA_DEVICE_API_VERSION_3_1.
  2595. *
  2596. * Return values:
  2597. *
  2598. * 0: On a successful flush of the camera HAL.
  2599. *
  2600. * -EINVAL: If the input is malformed (the device is not valid).
  2601. *
  2602. * -ENODEV: If the camera device has encountered a serious error. After this
  2603. * error is returned, only the close() method can be successfully
  2604. * called by the framework.
  2605. */
  2606. int (*flush)(const struct camera3_device *);
  2607. /* reserved for future use */
  2608. void *reserved[8];
  2609. } camera3_device_ops_t;
  2610. /**********************************************************************
  2611. *
  2612. * Camera device definition
  2613. *
  2614. */
  2615. typedef struct camera3_device {
  2616. /**
  2617. * common.version must equal CAMERA_DEVICE_API_VERSION_3_0 to identify this
  2618. * device as implementing version 3.0 of the camera device HAL.
  2619. *
  2620. * Performance requirements:
  2621. *
  2622. * Camera open (common.module->common.methods->open) should return in 200ms, and must return
  2623. * in 500ms.
  2624. * Camera close (common.close) should return in 200ms, and must return in 500ms.
  2625. *
  2626. */
  2627. hw_device_t common;
  2628. camera3_device_ops_t *ops;
  2629. void *priv;
  2630. } camera3_device_t;
  2631. __END_DECLS
  2632. #endif /* #ifdef ANDROID_INCLUDE_CAMERA3_H */