GoogleGit

blob: 2bb3ba1f7bb06374ab656e6531d4c77875c680e4 [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_BIDIRECTIONAL stream.
  1066. *
  1067. * For this use case, the bidirectional stream will be used by the framework as follows:
  1068. *
  1069. * 1. The framework includes a buffer from this stream as output buffer in a
  1070. * request as normal.
  1071. *
  1072. * 2. Once the HAL device returns a filled output buffer to the framework,
  1073. * the framework may do one of two things with the filled buffer:
  1074. *
  1075. * 2. a. The framework uses the filled data, and returns the now-used buffer
  1076. * to the stream queue for reuse. This behavior exactly matches the
  1077. * OUTPUT type of stream.
  1078. *
  1079. * 2. b. The framework wants to reprocess the filled data, and uses the
  1080. * buffer as an input buffer for a request. Once the HAL device has
  1081. * used the reprocessing buffer, it then returns it to the
  1082. * framework. The framework then returns the now-used buffer to the
  1083. * stream queue for reuse.
  1084. *
  1085. * 3. The HAL device will be given the buffer again as an output buffer for
  1086. * a request at some future point.
  1087. *
  1088. * For ZSL use case, the pixel format for bidirectional stream will be
  1089. * HAL_PIXEL_FORMAT_RAW_OPAQUE or HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED if it
  1090. * is listed in android.scaler.availableInputOutputFormatsMap. When
  1091. * HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, the gralloc
  1092. * usage flags for the consumer endpoint will be set to GRALLOC_USAGE_HW_CAMERA_ZSL.
  1093. * A configuration stream list that has BIDIRECTIONAL stream used as input, will
  1094. * usually also have a distinct OUTPUT stream to get the reprocessing data. For example,
  1095. * for the ZSL use case, the stream list might be configured with the following:
  1096. *
  1097. * - A HAL_PIXEL_FORMAT_RAW_OPAQUE bidirectional stream is used
  1098. * as input.
  1099. * - And a HAL_PIXEL_FORMAT_BLOB (JPEG) output stream.
  1100. *
  1101. */
  1102. /**
  1103. * S9. Notes on Controls and Metadata
  1104. *
  1105. * This section contains notes about the interpretation and usage of various metadata tags.
  1106. *
  1107. * S9.1 HIGH_QUALITY and FAST modes.
  1108. *
  1109. * Many camera post-processing blocks may be listed as having HIGH_QUALITY,
  1110. * FAST, and OFF operating modes. These blocks will typically also have an
  1111. * 'available modes' tag representing which of these operating modes are
  1112. * available on a given device. The general policy regarding implementing
  1113. * these modes is as follows:
  1114. *
  1115. * 1. Operating mode controls of hardware blocks that cannot be disabled
  1116. * must not list OFF in their corresponding 'available modes' tags.
  1117. *
  1118. * 2. OFF will always be included in their corresponding 'available modes'
  1119. * tag if it is possible to disable that hardware block.
  1120. *
  1121. * 3. FAST must always be included in the 'available modes' tags for all
  1122. * post-processing blocks supported on the device. If a post-processing
  1123. * block also has a slower and higher quality operating mode that does
  1124. * not meet the framerate requirements for FAST mode, HIGH_QUALITY should
  1125. * be included in the 'available modes' tag to represent this operating
  1126. * mode.
  1127. */
  1128. __BEGIN_DECLS
  1129. struct camera3_device;
  1130. /**********************************************************************
  1131. *
  1132. * Camera3 stream and stream buffer definitions.
  1133. *
  1134. * These structs and enums define the handles and contents of the input and
  1135. * output streams connecting the HAL to various framework and application buffer
  1136. * consumers. Each stream is backed by a gralloc buffer queue.
  1137. *
  1138. */
  1139. /**
  1140. * camera3_stream_type_t:
  1141. *
  1142. * The type of the camera stream, which defines whether the camera HAL device is
  1143. * the producer or the consumer for that stream, and how the buffers of the
  1144. * stream relate to the other streams.
  1145. */
  1146. typedef enum camera3_stream_type {
  1147. /**
  1148. * This stream is an output stream; the camera HAL device will be
  1149. * responsible for filling buffers from this stream with newly captured or
  1150. * reprocessed image data.
  1151. */
  1152. CAMERA3_STREAM_OUTPUT = 0,
  1153. /**
  1154. * This stream is an input stream; the camera HAL device will be responsible
  1155. * for reading buffers from this stream and sending them through the camera
  1156. * processing pipeline, as if the buffer was a newly captured image from the
  1157. * imager.
  1158. *
  1159. * The pixel format for input stream can be any format reported by
  1160. * android.scaler.availableInputOutputFormatsMap. The pixel format of the
  1161. * output stream that is used to produce the reprocessing data may be any
  1162. * format reported by android.scaler.availableStreamConfigurations. The
  1163. * supported input/output stream combinations depends the camera device
  1164. * capabilities, see android.scaler.availableInputOutputFormatsMap for
  1165. * stream map details.
  1166. *
  1167. * This kind of stream is generally used to reprocess data into higher
  1168. * quality images (that otherwise would cause a frame rate performance
  1169. * loss), or to do off-line reprocessing.
  1170. *
  1171. */
  1172. CAMERA3_STREAM_INPUT = 1,
  1173. /**
  1174. * This stream can be used for input and output. Typically, the stream is
  1175. * used as an output stream, but occasionally one already-filled buffer may
  1176. * be sent back to the HAL device for reprocessing.
  1177. *
  1178. * This kind of stream is meant generally for Zero Shutter Lag (ZSL)
  1179. * features, where copying the captured image from the output buffer to the
  1180. * reprocessing input buffer would be expensive. See S8.1 for more details.
  1181. *
  1182. * Note that the HAL will always be reprocessing data it produced.
  1183. *
  1184. */
  1185. CAMERA3_STREAM_BIDIRECTIONAL = 2,
  1186. /**
  1187. * Total number of framework-defined stream types
  1188. */
  1189. CAMERA3_NUM_STREAM_TYPES
  1190. } camera3_stream_type_t;
  1191. /**
  1192. * camera3_stream_t:
  1193. *
  1194. * A handle to a single camera input or output stream. A stream is defined by
  1195. * the framework by its buffer resolution and format, and additionally by the
  1196. * HAL with the gralloc usage flags and the maximum in-flight buffer count.
  1197. *
  1198. * The stream structures are owned by the framework, but pointers to a
  1199. * camera3_stream passed into the HAL by configure_streams() are valid until the
  1200. * end of the first subsequent configure_streams() call that _does not_ include
  1201. * that camera3_stream as an argument, or until the end of the close() call.
  1202. *
  1203. * All camera3_stream framework-controlled members are immutable once the
  1204. * camera3_stream is passed into configure_streams(). The HAL may only change
  1205. * the HAL-controlled parameters during a configure_streams() call, except for
  1206. * the contents of the private pointer.
  1207. *
  1208. * If a configure_streams() call returns a non-fatal error, all active streams
  1209. * remain valid as if configure_streams() had not been called.
  1210. *
  1211. * The endpoint of the stream is not visible to the camera HAL device.
  1212. * In DEVICE_API_VERSION_3_1, this was changed to share consumer usage flags
  1213. * on streams where the camera is a producer (OUTPUT and BIDIRECTIONAL stream
  1214. * types) see the usage field below.
  1215. */
  1216. typedef struct camera3_stream {
  1217. /*****
  1218. * Set by framework before configure_streams()
  1219. */
  1220. /**
  1221. * The type of the stream, one of the camera3_stream_type_t values.
  1222. */
  1223. int stream_type;
  1224. /**
  1225. * The width in pixels of the buffers in this stream
  1226. */
  1227. uint32_t width;
  1228. /**
  1229. * The height in pixels of the buffers in this stream
  1230. */
  1231. uint32_t height;
  1232. /**
  1233. * The pixel format for the buffers in this stream. Format is a value from
  1234. * the HAL_PIXEL_FORMAT_* list in system/core/include/system/graphics.h, or
  1235. * from device-specific headers.
  1236. *
  1237. * If HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, then the platform
  1238. * gralloc module will select a format based on the usage flags provided by
  1239. * the camera device and the other endpoint of the stream.
  1240. *
  1241. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1242. *
  1243. * The camera HAL device must inspect the buffers handed to it in the
  1244. * subsequent register_stream_buffers() call to obtain the
  1245. * implementation-specific format details, if necessary.
  1246. *
  1247. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1248. *
  1249. * register_stream_buffers() won't be called by the framework, so the HAL
  1250. * should configure the ISP and sensor pipeline based purely on the sizes,
  1251. * usage flags, and formats for the configured streams.
  1252. */
  1253. int format;
  1254. /*****
  1255. * Set by HAL during configure_streams().
  1256. */
  1257. /**
  1258. * The gralloc usage flags for this stream, as needed by the HAL. The usage
  1259. * flags are defined in gralloc.h (GRALLOC_USAGE_*), or in device-specific
  1260. * headers.
  1261. *
  1262. * For output streams, these are the HAL's producer usage flags. For input
  1263. * streams, these are the HAL's consumer usage flags. The usage flags from
  1264. * the producer and the consumer will be combined together and then passed
  1265. * to the platform gralloc HAL module for allocating the gralloc buffers for
  1266. * each stream.
  1267. *
  1268. * Version information:
  1269. *
  1270. * == CAMERA_DEVICE_API_VERSION_3_0:
  1271. *
  1272. * No initial value guaranteed when passed via configure_streams().
  1273. * HAL may not use this field as input, and must write over this field
  1274. * with its usage flags.
  1275. *
  1276. * >= CAMERA_DEVICE_API_VERSION_3_1:
  1277. *
  1278. * For stream_type OUTPUT and BIDIRECTIONAL, when passed via
  1279. * configure_streams(), the initial value of this is the consumer's
  1280. * usage flags. The HAL may use these consumer flags to decide stream
  1281. * configuration.
  1282. * For stream_type INPUT, when passed via configure_streams(), the initial
  1283. * value of this is 0.
  1284. * For all streams passed via configure_streams(), the HAL must write
  1285. * over this field with its usage flags.
  1286. */
  1287. uint32_t usage;
  1288. /**
  1289. * The maximum number of buffers the HAL device may need to have dequeued at
  1290. * the same time. The HAL device may not have more buffers in-flight from
  1291. * this stream than this value.
  1292. */
  1293. uint32_t max_buffers;
  1294. /**
  1295. * A handle to HAL-private information for the stream. Will not be inspected
  1296. * by the framework code.
  1297. */
  1298. void *priv;
  1299. } camera3_stream_t;
  1300. /**
  1301. * camera3_stream_configuration_t:
  1302. *
  1303. * A structure of stream definitions, used by configure_streams(). This
  1304. * structure defines all the output streams and the reprocessing input
  1305. * stream for the current camera use case.
  1306. */
  1307. typedef struct camera3_stream_configuration {
  1308. /**
  1309. * The total number of streams requested by the framework. This includes
  1310. * both input and output streams. The number of streams will be at least 1,
  1311. * and there will be at least one output-capable stream.
  1312. */
  1313. uint32_t num_streams;
  1314. /**
  1315. * An array of camera stream pointers, defining the input/output
  1316. * configuration for the camera HAL device.
  1317. *
  1318. * At most one input-capable stream may be defined (INPUT or BIDIRECTIONAL)
  1319. * in a single configuration.
  1320. *
  1321. * At least one output-capable stream must be defined (OUTPUT or
  1322. * BIDIRECTIONAL).
  1323. */
  1324. camera3_stream_t **streams;
  1325. } camera3_stream_configuration_t;
  1326. /**
  1327. * camera3_buffer_status_t:
  1328. *
  1329. * The current status of a single stream buffer.
  1330. */
  1331. typedef enum camera3_buffer_status {
  1332. /**
  1333. * The buffer is in a normal state, and can be used after waiting on its
  1334. * sync fence.
  1335. */
  1336. CAMERA3_BUFFER_STATUS_OK = 0,
  1337. /**
  1338. * The buffer does not contain valid data, and the data in it should not be
  1339. * used. The sync fence must still be waited on before reusing the buffer.
  1340. */
  1341. CAMERA3_BUFFER_STATUS_ERROR = 1
  1342. } camera3_buffer_status_t;
  1343. /**
  1344. * camera3_stream_buffer_t:
  1345. *
  1346. * A single buffer from a camera3 stream. It includes a handle to its parent
  1347. * stream, the handle to the gralloc buffer itself, and sync fences
  1348. *
  1349. * The buffer does not specify whether it is to be used for input or output;
  1350. * that is determined by its parent stream type and how the buffer is passed to
  1351. * the HAL device.
  1352. */
  1353. typedef struct camera3_stream_buffer {
  1354. /**
  1355. * The handle of the stream this buffer is associated with
  1356. */
  1357. camera3_stream_t *stream;
  1358. /**
  1359. * The native handle to the buffer
  1360. */
  1361. buffer_handle_t *buffer;
  1362. /**
  1363. * Current state of the buffer, one of the camera3_buffer_status_t
  1364. * values. The framework will not pass buffers to the HAL that are in an
  1365. * error state. In case a buffer could not be filled by the HAL, it must
  1366. * have its status set to CAMERA3_BUFFER_STATUS_ERROR when returned to the
  1367. * framework with process_capture_result().
  1368. */
  1369. int status;
  1370. /**
  1371. * The acquire sync fence for this buffer. The HAL must wait on this fence
  1372. * fd before attempting to read from or write to this buffer.
  1373. *
  1374. * The framework may be set to -1 to indicate that no waiting is necessary
  1375. * for this buffer.
  1376. *
  1377. * When the HAL returns an output buffer to the framework with
  1378. * process_capture_result(), the acquire_fence must be set to -1. If the HAL
  1379. * never waits on the acquire_fence due to an error in filling a buffer,
  1380. * when calling process_capture_result() the HAL must set the release_fence
  1381. * of the buffer to be the acquire_fence passed to it by the framework. This
  1382. * will allow the framework to wait on the fence before reusing the buffer.
  1383. *
  1384. * For input buffers, the HAL must not change the acquire_fence field during
  1385. * the process_capture_request() call.
  1386. *
  1387. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1388. *
  1389. * When the HAL returns an input buffer to the framework with
  1390. * process_capture_result(), the acquire_fence must be set to -1. If the HAL
  1391. * never waits on input buffer acquire fence due to an error, the sync
  1392. * fences should be handled similarly to the way they are handled for output
  1393. * buffers.
  1394. */
  1395. int acquire_fence;
  1396. /**
  1397. * The release sync fence for this buffer. The HAL must set this fence when
  1398. * returning buffers to the framework, or write -1 to indicate that no
  1399. * waiting is required for this buffer.
  1400. *
  1401. * For the output buffers, the fences must be set in the output_buffers
  1402. * array passed to process_capture_result().
  1403. *
  1404. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1405. *
  1406. * For the input buffer, the release fence must be set by the
  1407. * process_capture_request() call.
  1408. *
  1409. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1410. *
  1411. * For the input buffer, the fences must be set in the input_buffer
  1412. * passed to process_capture_result().
  1413. *
  1414. * After signaling the release_fence for this buffer, the HAL
  1415. * should not make any further attempts to access this buffer as the
  1416. * ownership has been fully transferred back to the framework.
  1417. *
  1418. * If a fence of -1 was specified then the ownership of this buffer
  1419. * is transferred back immediately upon the call of process_capture_result.
  1420. */
  1421. int release_fence;
  1422. } camera3_stream_buffer_t;
  1423. /**
  1424. * camera3_stream_buffer_set_t:
  1425. *
  1426. * The complete set of gralloc buffers for a stream. This structure is given to
  1427. * register_stream_buffers() to allow the camera HAL device to register/map/etc
  1428. * newly allocated stream buffers.
  1429. *
  1430. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1431. *
  1432. * Deprecated (and not used). In particular,
  1433. * register_stream_buffers is also deprecated and will never be invoked.
  1434. *
  1435. */
  1436. typedef struct camera3_stream_buffer_set {
  1437. /**
  1438. * The stream handle for the stream these buffers belong to
  1439. */
  1440. camera3_stream_t *stream;
  1441. /**
  1442. * The number of buffers in this stream. It is guaranteed to be at least
  1443. * stream->max_buffers.
  1444. */
  1445. uint32_t num_buffers;
  1446. /**
  1447. * The array of gralloc buffer handles for this stream. If the stream format
  1448. * is set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, the camera HAL device
  1449. * should inspect the passed-in buffers to determine any platform-private
  1450. * pixel format information.
  1451. */
  1452. buffer_handle_t **buffers;
  1453. } camera3_stream_buffer_set_t;
  1454. /**
  1455. * camera3_jpeg_blob:
  1456. *
  1457. * Transport header for compressed JPEG buffers in output streams.
  1458. *
  1459. * To capture JPEG images, a stream is created using the pixel format
  1460. * HAL_PIXEL_FORMAT_BLOB. The buffer size for the stream is calculated by the
  1461. * framework, based on the static metadata field android.jpeg.maxSize. Since
  1462. * compressed JPEG images are of variable size, the HAL needs to include the
  1463. * final size of the compressed image using this structure inside the output
  1464. * stream buffer. The JPEG blob ID field must be set to CAMERA3_JPEG_BLOB_ID.
  1465. *
  1466. * Transport header should be at the end of the JPEG output stream buffer. That
  1467. * means the jpeg_blob_id must start at byte[buffer_size -
  1468. * sizeof(camera3_jpeg_blob)], where the buffer_size is the size of gralloc buffer.
  1469. * Any HAL using this transport header must account for it in android.jpeg.maxSize
  1470. * The JPEG data itself starts at the beginning of the buffer and should be
  1471. * jpeg_size bytes long.
  1472. */
  1473. typedef struct camera3_jpeg_blob {
  1474. uint16_t jpeg_blob_id;
  1475. uint32_t jpeg_size;
  1476. } camera3_jpeg_blob_t;
  1477. enum {
  1478. CAMERA3_JPEG_BLOB_ID = 0x00FF
  1479. };
  1480. /**********************************************************************
  1481. *
  1482. * Message definitions for the HAL notify() callback.
  1483. *
  1484. * These definitions are used for the HAL notify callback, to signal
  1485. * asynchronous events from the HAL device to the Android framework.
  1486. *
  1487. */
  1488. /**
  1489. * camera3_msg_type:
  1490. *
  1491. * Indicates the type of message sent, which specifies which member of the
  1492. * message union is valid.
  1493. *
  1494. */
  1495. typedef enum camera3_msg_type {
  1496. /**
  1497. * An error has occurred. camera3_notify_msg.message.error contains the
  1498. * error information.
  1499. */
  1500. CAMERA3_MSG_ERROR = 1,
  1501. /**
  1502. * The exposure of a given request has
  1503. * begun. camera3_notify_msg.message.shutter contains the information
  1504. * the capture.
  1505. */
  1506. CAMERA3_MSG_SHUTTER = 2,
  1507. /**
  1508. * Number of framework message types
  1509. */
  1510. CAMERA3_NUM_MESSAGES
  1511. } camera3_msg_type_t;
  1512. /**
  1513. * Defined error codes for CAMERA_MSG_ERROR
  1514. */
  1515. typedef enum camera3_error_msg_code {
  1516. /**
  1517. * A serious failure occured. No further frames or buffer streams will
  1518. * be produced by the device. Device should be treated as closed. The
  1519. * client must reopen the device to use it again. The frame_number field
  1520. * is unused.
  1521. */
  1522. CAMERA3_MSG_ERROR_DEVICE = 1,
  1523. /**
  1524. * An error has occurred in processing a request. No output (metadata or
  1525. * buffers) will be produced for this request. The frame_number field
  1526. * specifies which request has been dropped. Subsequent requests are
  1527. * unaffected, and the device remains operational.
  1528. */
  1529. CAMERA3_MSG_ERROR_REQUEST = 2,
  1530. /**
  1531. * An error has occurred in producing an output result metadata buffer
  1532. * for a request, but output stream buffers for it will still be
  1533. * available. Subsequent requests are unaffected, and the device remains
  1534. * operational. The frame_number field specifies the request for which
  1535. * result metadata won't be available.
  1536. */
  1537. CAMERA3_MSG_ERROR_RESULT = 3,
  1538. /**
  1539. * An error has occurred in placing an output buffer into a stream for a
  1540. * request. The frame metadata and other buffers may still be
  1541. * available. Subsequent requests are unaffected, and the device remains
  1542. * operational. The frame_number field specifies the request for which the
  1543. * buffer was dropped, and error_stream contains a pointer to the stream
  1544. * that dropped the frame.u
  1545. */
  1546. CAMERA3_MSG_ERROR_BUFFER = 4,
  1547. /**
  1548. * Number of error types
  1549. */
  1550. CAMERA3_MSG_NUM_ERRORS
  1551. } camera3_error_msg_code_t;
  1552. /**
  1553. * camera3_error_msg_t:
  1554. *
  1555. * Message contents for CAMERA3_MSG_ERROR
  1556. */
  1557. typedef struct camera3_error_msg {
  1558. /**
  1559. * Frame number of the request the error applies to. 0 if the frame number
  1560. * isn't applicable to the error.
  1561. */
  1562. uint32_t frame_number;
  1563. /**
  1564. * Pointer to the stream that had a failure. NULL if the stream isn't
  1565. * applicable to the error.
  1566. */
  1567. camera3_stream_t *error_stream;
  1568. /**
  1569. * The code for this error; one of the CAMERA_MSG_ERROR enum values.
  1570. */
  1571. int error_code;
  1572. } camera3_error_msg_t;
  1573. /**
  1574. * camera3_shutter_msg_t:
  1575. *
  1576. * Message contents for CAMERA3_MSG_SHUTTER
  1577. */
  1578. typedef struct camera3_shutter_msg {
  1579. /**
  1580. * Frame number of the request that has begun exposure
  1581. */
  1582. uint32_t frame_number;
  1583. /**
  1584. * Timestamp for the start of capture. This must match the capture result
  1585. * metadata's sensor exposure start timestamp.
  1586. */
  1587. uint64_t timestamp;
  1588. } camera3_shutter_msg_t;
  1589. /**
  1590. * camera3_notify_msg_t:
  1591. *
  1592. * The message structure sent to camera3_callback_ops_t.notify()
  1593. */
  1594. typedef struct camera3_notify_msg {
  1595. /**
  1596. * The message type. One of camera3_notify_msg_type, or a private extension.
  1597. */
  1598. int type;
  1599. union {
  1600. /**
  1601. * Error message contents. Valid if type is CAMERA3_MSG_ERROR
  1602. */
  1603. camera3_error_msg_t error;
  1604. /**
  1605. * Shutter message contents. Valid if type is CAMERA3_MSG_SHUTTER
  1606. */
  1607. camera3_shutter_msg_t shutter;
  1608. /**
  1609. * Generic message contents. Used to ensure a minimum size for custom
  1610. * message types.
  1611. */
  1612. uint8_t generic[32];
  1613. } message;
  1614. } camera3_notify_msg_t;
  1615. /**********************************************************************
  1616. *
  1617. * Capture request/result definitions for the HAL process_capture_request()
  1618. * method, and the process_capture_result() callback.
  1619. *
  1620. */
  1621. /**
  1622. * camera3_request_template_t:
  1623. *
  1624. * Available template types for
  1625. * camera3_device_ops.construct_default_request_settings()
  1626. */
  1627. typedef enum camera3_request_template {
  1628. /**
  1629. * Standard camera preview operation with 3A on auto.
  1630. */
  1631. CAMERA3_TEMPLATE_PREVIEW = 1,
  1632. /**
  1633. * Standard camera high-quality still capture with 3A and flash on auto.
  1634. */
  1635. CAMERA3_TEMPLATE_STILL_CAPTURE = 2,
  1636. /**
  1637. * Standard video recording plus preview with 3A on auto, torch off.
  1638. */
  1639. CAMERA3_TEMPLATE_VIDEO_RECORD = 3,
  1640. /**
  1641. * High-quality still capture while recording video. Application will
  1642. * include preview, video record, and full-resolution YUV or JPEG streams in
  1643. * request. Must not cause stuttering on video stream. 3A on auto.
  1644. */
  1645. CAMERA3_TEMPLATE_VIDEO_SNAPSHOT = 4,
  1646. /**
  1647. * Zero-shutter-lag mode. Application will request preview and
  1648. * full-resolution data for each frame, and reprocess it to JPEG when a
  1649. * still image is requested by user. Settings should provide highest-quality
  1650. * full-resolution images without compromising preview frame rate. 3A on
  1651. * auto.
  1652. */
  1653. CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG = 5,
  1654. /**
  1655. * A basic template for direct application control of capture
  1656. * parameters. All automatic control is disabled (auto-exposure, auto-white
  1657. * balance, auto-focus), and post-processing parameters are set to preview
  1658. * quality. The manual capture parameters (exposure, sensitivity, etc.)
  1659. * are set to reasonable defaults, but should be overridden by the
  1660. * application depending on the intended use case.
  1661. */
  1662. CAMERA3_TEMPLATE_MANUAL = 6,
  1663. /* Total number of templates */
  1664. CAMERA3_TEMPLATE_COUNT,
  1665. /**
  1666. * First value for vendor-defined request templates
  1667. */
  1668. CAMERA3_VENDOR_TEMPLATE_START = 0x40000000
  1669. } camera3_request_template_t;
  1670. /**
  1671. * camera3_capture_request_t:
  1672. *
  1673. * A single request for image capture/buffer reprocessing, sent to the Camera
  1674. * HAL device by the framework in process_capture_request().
  1675. *
  1676. * The request contains the settings to be used for this capture, and the set of
  1677. * output buffers to write the resulting image data in. It may optionally
  1678. * contain an input buffer, in which case the request is for reprocessing that
  1679. * input buffer instead of capturing a new image with the camera sensor. The
  1680. * capture is identified by the frame_number.
  1681. *
  1682. * In response, the camera HAL device must send a camera3_capture_result
  1683. * structure asynchronously to the framework, using the process_capture_result()
  1684. * callback.
  1685. */
  1686. typedef struct camera3_capture_request {
  1687. /**
  1688. * The frame number is an incrementing integer set by the framework to
  1689. * uniquely identify this capture. It needs to be returned in the result
  1690. * call, and is also used to identify the request in asynchronous
  1691. * notifications sent to camera3_callback_ops_t.notify().
  1692. */
  1693. uint32_t frame_number;
  1694. /**
  1695. * The settings buffer contains the capture and processing parameters for
  1696. * the request. As a special case, a NULL settings buffer indicates that the
  1697. * settings are identical to the most-recently submitted capture request. A
  1698. * NULL buffer cannot be used as the first submitted request after a
  1699. * configure_streams() call.
  1700. */
  1701. const camera_metadata_t *settings;
  1702. /**
  1703. * The input stream buffer to use for this request, if any.
  1704. *
  1705. * If input_buffer is NULL, then the request is for a new capture from the
  1706. * imager. If input_buffer is valid, the request is for reprocessing the
  1707. * image contained in input_buffer.
  1708. *
  1709. * In the latter case, the HAL must set the release_fence of the
  1710. * input_buffer to a valid sync fence, or to -1 if the HAL does not support
  1711. * sync, before process_capture_request() returns.
  1712. *
  1713. * The HAL is required to wait on the acquire sync fence of the input buffer
  1714. * before accessing it.
  1715. *
  1716. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1717. *
  1718. * Any input buffer included here will have been registered with the HAL
  1719. * through register_stream_buffers() before its inclusion in a request.
  1720. *
  1721. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1722. *
  1723. * The buffers will not have been pre-registered with the HAL.
  1724. * Subsequent requests may reuse buffers, or provide entirely new buffers.
  1725. */
  1726. camera3_stream_buffer_t *input_buffer;
  1727. /**
  1728. * The number of output buffers for this capture request. Must be at least
  1729. * 1.
  1730. */
  1731. uint32_t num_output_buffers;
  1732. /**
  1733. * An array of num_output_buffers stream buffers, to be filled with image
  1734. * data from this capture/reprocess. The HAL must wait on the acquire fences
  1735. * of each stream buffer before writing to them.
  1736. *
  1737. * The HAL takes ownership of the actual buffer_handle_t entries in
  1738. * output_buffers; the framework does not access them until they are
  1739. * returned in a camera3_capture_result_t.
  1740. *
  1741. * <= CAMERA_DEVICE_API_VERSION_3_1:
  1742. *
  1743. * All the buffers included here will have been registered with the HAL
  1744. * through register_stream_buffers() before their inclusion in a request.
  1745. *
  1746. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1747. *
  1748. * Any or all of the buffers included here may be brand new in this
  1749. * request (having never before seen by the HAL).
  1750. */
  1751. const camera3_stream_buffer_t *output_buffers;
  1752. } camera3_capture_request_t;
  1753. /**
  1754. * camera3_capture_result_t:
  1755. *
  1756. * The result of a single capture/reprocess by the camera HAL device. This is
  1757. * sent to the framework asynchronously with process_capture_result(), in
  1758. * response to a single capture request sent to the HAL with
  1759. * process_capture_request(). Multiple process_capture_result() calls may be
  1760. * performed by the HAL for each request.
  1761. *
  1762. * Each call, all with the same frame
  1763. * number, may contain some subset of the output buffers, and/or the result
  1764. * metadata. The metadata may only be provided once for a given frame number;
  1765. * all other calls must set the result metadata to NULL.
  1766. *
  1767. * The result structure contains the output metadata from this capture, and the
  1768. * set of output buffers that have been/will be filled for this capture. Each
  1769. * output buffer may come with a release sync fence that the framework will wait
  1770. * on before reading, in case the buffer has not yet been filled by the HAL.
  1771. *
  1772. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1773. *
  1774. * The metadata may be provided multiple times for a single frame number. The
  1775. * framework will accumulate together the final result set by combining each
  1776. * partial result together into the total result set.
  1777. *
  1778. * If an input buffer is given in a request, the HAL must return it in one of
  1779. * the process_capture_result calls, and the call may be to just return the input
  1780. * buffer, without metadata and output buffers; the sync fences must be handled
  1781. * the same way they are done for output buffers.
  1782. *
  1783. *
  1784. * Performance considerations:
  1785. *
  1786. * Applications will also receive these partial results immediately, so sending
  1787. * partial results is a highly recommended performance optimization to avoid
  1788. * the total pipeline latency before sending the results for what is known very
  1789. * early on in the pipeline.
  1790. *
  1791. * A typical use case might be calculating the AF state halfway through the
  1792. * pipeline; by sending the state back to the framework immediately, we get a
  1793. * 50% performance increase and perceived responsiveness of the auto-focus.
  1794. *
  1795. */
  1796. typedef struct camera3_capture_result {
  1797. /**
  1798. * The frame number is an incrementing integer set by the framework in the
  1799. * submitted request to uniquely identify this capture. It is also used to
  1800. * identify the request in asynchronous notifications sent to
  1801. * camera3_callback_ops_t.notify().
  1802. */
  1803. uint32_t frame_number;
  1804. /**
  1805. * The result metadata for this capture. This contains information about the
  1806. * final capture parameters, the state of the capture and post-processing
  1807. * hardware, the state of the 3A algorithms, if enabled, and the output of
  1808. * any enabled statistics units.
  1809. *
  1810. * Only one call to process_capture_result() with a given frame_number may
  1811. * include the result metadata. All other calls for the same frame_number
  1812. * must set this to NULL.
  1813. *
  1814. * If there was an error producing the result metadata, result must be an
  1815. * empty metadata buffer, and notify() must be called with ERROR_RESULT.
  1816. *
  1817. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1818. *
  1819. * Multiple calls to process_capture_result() with a given frame_number
  1820. * may include the result metadata.
  1821. *
  1822. * Partial metadata submitted should not include any metadata key returned
  1823. * in a previous partial result for a given frame. Each new partial result
  1824. * for that frame must also set a distinct partial_result value.
  1825. *
  1826. * If notify has been called with ERROR_RESULT, all further partial
  1827. * results for that frame are ignored by the framework.
  1828. */
  1829. const camera_metadata_t *result;
  1830. /**
  1831. * The number of output buffers returned in this result structure. Must be
  1832. * less than or equal to the matching capture request's count. If this is
  1833. * less than the buffer count in the capture request, at least one more call
  1834. * to process_capture_result with the same frame_number must be made, to
  1835. * return the remaining output buffers to the framework. This may only be
  1836. * zero if the structure includes valid result metadata or an input buffer
  1837. * is returned in this result.
  1838. */
  1839. uint32_t num_output_buffers;
  1840. /**
  1841. * The handles for the output stream buffers for this capture. They may not
  1842. * yet be filled at the time the HAL calls process_capture_result(); the
  1843. * framework will wait on the release sync fences provided by the HAL before
  1844. * reading the buffers.
  1845. *
  1846. * The HAL must set the stream buffer's release sync fence to a valid sync
  1847. * fd, or to -1 if the buffer has already been filled.
  1848. *
  1849. * If the HAL encounters an error while processing the buffer, and the
  1850. * buffer is not filled, the buffer's status field must be set to
  1851. * CAMERA3_BUFFER_STATUS_ERROR. If the HAL did not wait on the acquire fence
  1852. * before encountering the error, the acquire fence should be copied into
  1853. * the release fence, to allow the framework to wait on the fence before
  1854. * reusing the buffer.
  1855. *
  1856. * The acquire fence must be set to -1 for all output buffers. If
  1857. * num_output_buffers is zero, this may be NULL. In that case, at least one
  1858. * more process_capture_result call must be made by the HAL to provide the
  1859. * output buffers.
  1860. *
  1861. * When process_capture_result is called with a new buffer for a frame,
  1862. * all previous frames' buffers for that corresponding stream must have been
  1863. * already delivered (the fences need not have yet been signaled).
  1864. *
  1865. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1866. *
  1867. * Gralloc buffers for a frame may be sent to framework before the
  1868. * corresponding SHUTTER-notify.
  1869. *
  1870. * Performance considerations:
  1871. *
  1872. * Buffers delivered to the framework will not be dispatched to the
  1873. * application layer until a start of exposure timestamp has been received
  1874. * via a SHUTTER notify() call. It is highly recommended to
  1875. * dispatch that call as early as possible.
  1876. */
  1877. const camera3_stream_buffer_t *output_buffers;
  1878. /**
  1879. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1880. *
  1881. * The handle for the input stream buffer for this capture. It may not
  1882. * yet be consumed at the time the HAL calls process_capture_result(); the
  1883. * framework will wait on the release sync fences provided by the HAL before
  1884. * reusing the buffer.
  1885. *
  1886. * The HAL should handle the sync fences the same way they are done for
  1887. * output_buffers.
  1888. *
  1889. * Only one input buffer is allowed to be sent per request. Similarly to
  1890. * output buffers, the ordering of returned input buffers must be
  1891. * maintained by the HAL.
  1892. *
  1893. * Performance considerations:
  1894. *
  1895. * The input buffer should be returned as early as possible. If the HAL
  1896. * supports sync fences, it can call process_capture_result to hand it back
  1897. * with sync fences being set appropriately. If the sync fences are not
  1898. * supported, the buffer can only be returned when it is consumed, which
  1899. * may take long time; the HAL may choose to copy this input buffer to make
  1900. * the buffer return sooner.
  1901. */
  1902. const camera3_stream_buffer_t *input_buffer;
  1903. /**
  1904. * >= CAMERA_DEVICE_API_VERSION_3_2:
  1905. *
  1906. * In order to take advantage of partial results, the HAL must set the
  1907. * static metadata android.request.partialResultCount to the number of
  1908. * partial results it will send for each frame.
  1909. *
  1910. * Each new capture result with a partial result must set
  1911. * this field (partial_result) to a distinct inclusive value between
  1912. * 1 and android.request.partialResultCount.
  1913. *
  1914. * HALs not wishing to take advantage of this feature must not
  1915. * set an android.request.partialResultCount or partial_result to a value
  1916. * other than 1.
  1917. *
  1918. * This value must be set to 0 when a capture result contains buffers only
  1919. * and no metadata.
  1920. */
  1921. uint32_t partial_result;
  1922. } camera3_capture_result_t;
  1923. /**********************************************************************
  1924. *
  1925. * Callback methods for the HAL to call into the framework.
  1926. *
  1927. * These methods are used to return metadata and image buffers for a completed
  1928. * or failed captures, and to notify the framework of asynchronous events such
  1929. * as errors.
  1930. *
  1931. * The framework will not call back into the HAL from within these callbacks,
  1932. * and these calls will not block for extended periods.
  1933. *
  1934. */
  1935. typedef struct camera3_callback_ops {
  1936. /**
  1937. * process_capture_result:
  1938. *
  1939. * Send results from a completed capture to the framework.
  1940. * process_capture_result() may be invoked multiple times by the HAL in
  1941. * response to a single capture request. This allows, for example, the
  1942. * metadata and low-resolution buffers to be returned in one call, and
  1943. * post-processed JPEG buffers in a later call, once it is available. Each
  1944. * call must include the frame number of the request it is returning
  1945. * metadata or buffers for.
  1946. *
  1947. * A component (buffer or metadata) of the complete result may only be
  1948. * included in one process_capture_result call. A buffer for each stream,
  1949. * and the result metadata, must be returned by the HAL for each request in
  1950. * one of the process_capture_result calls, even in case of errors producing
  1951. * some of the output. A call to process_capture_result() with neither
  1952. * output buffers or result metadata is not allowed.
  1953. *
  1954. * The order of returning metadata and buffers for a single result does not
  1955. * matter, but buffers for a given stream must be returned in FIFO order. So
  1956. * the buffer for request 5 for stream A must always be returned before the
  1957. * buffer for request 6 for stream A. This also applies to the result
  1958. * metadata; the metadata for request 5 must be returned before the metadata
  1959. * for request 6.
  1960. *
  1961. * However, different streams are independent of each other, so it is
  1962. * acceptable and expected that the buffer for request 5 for stream A may be
  1963. * returned after the buffer for request 6 for stream B is. And it is
  1964. * acceptable that the result metadata for request 6 for stream B is
  1965. * returned before the buffer for request 5 for stream A is.
  1966. *
  1967. * The HAL retains ownership of result structure, which only needs to be
  1968. * valid to access during this call. The framework will copy whatever it
  1969. * needs before this call returns.
  1970. *
  1971. * The output buffers do not need to be filled yet; the framework will wait
  1972. * on the stream buffer release sync fence before reading the buffer
  1973. * data. Therefore, this method should be called by the HAL as soon as
  1974. * possible, even if some or all of the output buffers are still in
  1975. * being filled. The HAL must include valid release sync fences into each
  1976. * output_buffers stream buffer entry, or -1 if that stream buffer is
  1977. * already filled.
  1978. *
  1979. * If the result buffer cannot be constructed for a request, the HAL should
  1980. * return an empty metadata buffer, but still provide the output buffers and
  1981. * their sync fences. In addition, notify() must be called with an
  1982. * ERROR_RESULT message.
  1983. *
  1984. * If an output buffer cannot be filled, its status field must be set to
  1985. * STATUS_ERROR. In addition, notify() must be called with a ERROR_BUFFER
  1986. * message.
  1987. *
  1988. * If the entire capture has failed, then this method still needs to be
  1989. * called to return the output buffers to the framework. All the buffer
  1990. * statuses should be STATUS_ERROR, and the result metadata should be an
  1991. * empty buffer. In addition, notify() must be called with a ERROR_REQUEST
  1992. * message. In this case, individual ERROR_RESULT/ERROR_BUFFER messages
  1993. * should not be sent.
  1994. *
  1995. * Performance requirements:
  1996. *
  1997. * This is a non-blocking call. The framework will return this call in 5ms.
  1998. *
  1999. * The pipeline latency (see S7 for definition) should be less than or equal to
  2000. * 4 frame intervals, and must be less than or equal to 8 frame intervals.
  2001. *
  2002. */
  2003. void (*process_capture_result)(const struct camera3_callback_ops *,
  2004. const camera3_capture_result_t *result);
  2005. /**
  2006. * notify:
  2007. *
  2008. * Asynchronous notification callback from the HAL, fired for various
  2009. * reasons. Only for information independent of frame capture, or that
  2010. * require specific timing. The ownership of the message structure remains
  2011. * with the HAL, and the msg only needs to be valid for the duration of this
  2012. * call.
  2013. *
  2014. * Multiple threads may call notify() simultaneously.
  2015. *
  2016. * <= CAMERA_DEVICE_API_VERSION_3_1:
  2017. *
  2018. * The notification for the start of exposure for a given request must be
  2019. * sent by the HAL before the first call to process_capture_result() for
  2020. * that request is made.
  2021. *
  2022. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2023. *
  2024. * Buffers delivered to the framework will not be dispatched to the
  2025. * application layer until a start of exposure timestamp has been received
  2026. * via a SHUTTER notify() call. It is highly recommended to
  2027. * dispatch this call as early as possible.
  2028. *
  2029. * ------------------------------------------------------------------------
  2030. * Performance requirements:
  2031. *
  2032. * This is a non-blocking call. The framework will return this call in 5ms.
  2033. */
  2034. void (*notify)(const struct camera3_callback_ops *,
  2035. const camera3_notify_msg_t *msg);
  2036. } camera3_callback_ops_t;
  2037. /**********************************************************************
  2038. *
  2039. * Camera device operations
  2040. *
  2041. */
  2042. typedef struct camera3_device_ops {
  2043. /**
  2044. * initialize:
  2045. *
  2046. * One-time initialization to pass framework callback function pointers to
  2047. * the HAL. Will be called once after a successful open() call, before any
  2048. * other functions are called on the camera3_device_ops structure.
  2049. *
  2050. * Performance requirements:
  2051. *
  2052. * This should be a non-blocking call. The HAL should return from this call
  2053. * in 5ms, and must return from this call in 10ms.
  2054. *
  2055. * Return values:
  2056. *
  2057. * 0: On successful initialization
  2058. *
  2059. * -ENODEV: If initialization fails. Only close() can be called successfully
  2060. * by the framework after this.
  2061. */
  2062. int (*initialize)(const struct camera3_device *,
  2063. const camera3_callback_ops_t *callback_ops);
  2064. /**********************************************************************
  2065. * Stream management
  2066. */
  2067. /**
  2068. * configure_streams:
  2069. *
  2070. * CAMERA_DEVICE_API_VERSION_3_0 only:
  2071. *
  2072. * Reset the HAL camera device processing pipeline and set up new input and
  2073. * output streams. This call replaces any existing stream configuration with
  2074. * the streams defined in the stream_list. This method will be called at
  2075. * least once after initialize() before a request is submitted with
  2076. * process_capture_request().
  2077. *
  2078. * The stream_list must contain at least one output-capable stream, and may
  2079. * not contain more than one input-capable stream.
  2080. *
  2081. * The stream_list may contain streams that are also in the currently-active
  2082. * set of streams (from the previous call to configure_stream()). These
  2083. * streams will already have valid values for usage, max_buffers, and the
  2084. * private pointer.
  2085. *
  2086. * If such a stream has already had its buffers registered,
  2087. * register_stream_buffers() will not be called again for the stream, and
  2088. * buffers from the stream can be immediately included in input requests.
  2089. *
  2090. * If the HAL needs to change the stream configuration for an existing
  2091. * stream due to the new configuration, it may rewrite the values of usage
  2092. * and/or max_buffers during the configure call.
  2093. *
  2094. * The framework will detect such a change, and will then reallocate the
  2095. * stream buffers, and call register_stream_buffers() again before using
  2096. * buffers from that stream in a request.
  2097. *
  2098. * If a currently-active stream is not included in stream_list, the HAL may
  2099. * safely remove any references to that stream. It will not be reused in a
  2100. * later configure() call by the framework, and all the gralloc buffers for
  2101. * it will be freed after the configure_streams() call returns.
  2102. *
  2103. * The stream_list structure is owned by the framework, and may not be
  2104. * accessed once this call completes. The address of an individual
  2105. * camera3_stream_t structure will remain valid for access by the HAL until
  2106. * the end of the first configure_stream() call which no longer includes
  2107. * that camera3_stream_t in the stream_list argument. The HAL may not change
  2108. * values in the stream structure outside of the private pointer, except for
  2109. * the usage and max_buffers members during the configure_streams() call
  2110. * itself.
  2111. *
  2112. * If the stream is new, the usage, max_buffer, and private pointer fields
  2113. * of the stream structure will all be set to 0. The HAL device must set
  2114. * these fields before the configure_streams() call returns. These fields
  2115. * are then used by the framework and the platform gralloc module to
  2116. * allocate the gralloc buffers for each stream.
  2117. *
  2118. * Before such a new stream can have its buffers included in a capture
  2119. * request, the framework will call register_stream_buffers() with that
  2120. * stream. However, the framework is not required to register buffers for
  2121. * _all_ streams before submitting a request. This allows for quick startup
  2122. * of (for example) a preview stream, with allocation for other streams
  2123. * happening later or concurrently.
  2124. *
  2125. * ------------------------------------------------------------------------
  2126. * CAMERA_DEVICE_API_VERSION_3_1 only:
  2127. *
  2128. * Reset the HAL camera device processing pipeline and set up new input and
  2129. * output streams. This call replaces any existing stream configuration with
  2130. * the streams defined in the stream_list. This method will be called at
  2131. * least once after initialize() before a request is submitted with
  2132. * process_capture_request().
  2133. *
  2134. * The stream_list must contain at least one output-capable stream, and may
  2135. * not contain more than one input-capable stream.
  2136. *
  2137. * The stream_list may contain streams that are also in the currently-active
  2138. * set of streams (from the previous call to configure_stream()). These
  2139. * streams will already have valid values for usage, max_buffers, and the
  2140. * private pointer.
  2141. *
  2142. * If such a stream has already had its buffers registered,
  2143. * register_stream_buffers() will not be called again for the stream, and
  2144. * buffers from the stream can be immediately included in input requests.
  2145. *
  2146. * If the HAL needs to change the stream configuration for an existing
  2147. * stream due to the new configuration, it may rewrite the values of usage
  2148. * and/or max_buffers during the configure call.
  2149. *
  2150. * The framework will detect such a change, and will then reallocate the
  2151. * stream buffers, and call register_stream_buffers() again before using
  2152. * buffers from that stream in a request.
  2153. *
  2154. * If a currently-active stream is not included in stream_list, the HAL may
  2155. * safely remove any references to that stream. It will not be reused in a
  2156. * later configure() call by the framework, and all the gralloc buffers for
  2157. * it will be freed after the configure_streams() call returns.
  2158. *
  2159. * The stream_list structure is owned by the framework, and may not be
  2160. * accessed once this call completes. The address of an individual
  2161. * camera3_stream_t structure will remain valid for access by the HAL until
  2162. * the end of the first configure_stream() call which no longer includes
  2163. * that camera3_stream_t in the stream_list argument. The HAL may not change
  2164. * values in the stream structure outside of the private pointer, except for
  2165. * the usage and max_buffers members during the configure_streams() call
  2166. * itself.
  2167. *
  2168. * If the stream is new, max_buffer, and private pointer fields of the
  2169. * stream structure will all be set to 0. The usage will be set to the
  2170. * consumer usage flags. The HAL device must set these fields before the
  2171. * configure_streams() call returns. These fields are then used by the
  2172. * framework and the platform gralloc module to allocate the gralloc
  2173. * buffers for each stream.
  2174. *
  2175. * Before such a new stream can have its buffers included in a capture
  2176. * request, the framework will call register_stream_buffers() with that
  2177. * stream. However, the framework is not required to register buffers for
  2178. * _all_ streams before submitting a request. This allows for quick startup
  2179. * of (for example) a preview stream, with allocation for other streams
  2180. * happening later or concurrently.
  2181. *
  2182. * ------------------------------------------------------------------------
  2183. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2184. *
  2185. * Reset the HAL camera device processing pipeline and set up new input and
  2186. * output streams. This call replaces any existing stream configuration with
  2187. * the streams defined in the stream_list. This method will be called at
  2188. * least once after initialize() before a request is submitted with
  2189. * process_capture_request().
  2190. *
  2191. * The stream_list must contain at least one output-capable stream, and may
  2192. * not contain more than one input-capable stream.
  2193. *
  2194. * The stream_list may contain streams that are also in the currently-active
  2195. * set of streams (from the previous call to configure_stream()). These
  2196. * streams will already have valid values for usage, max_buffers, and the
  2197. * private pointer.
  2198. *
  2199. * If the HAL needs to change the stream configuration for an existing
  2200. * stream due to the new configuration, it may rewrite the values of usage
  2201. * and/or max_buffers during the configure call.
  2202. *
  2203. * The framework will detect such a change, and may then reallocate the
  2204. * stream buffers before using buffers from that stream in a request.
  2205. *
  2206. * If a currently-active stream is not included in stream_list, the HAL may
  2207. * safely remove any references to that stream. It will not be reused in a
  2208. * later configure() call by the framework, and all the gralloc buffers for
  2209. * it will be freed after the configure_streams() call returns.
  2210. *
  2211. * The stream_list structure is owned by the framework, and may not be
  2212. * accessed once this call completes. The address of an individual
  2213. * camera3_stream_t structure will remain valid for access by the HAL until
  2214. * the end of the first configure_stream() call which no longer includes
  2215. * that camera3_stream_t in the stream_list argument. The HAL may not change
  2216. * values in the stream structure outside of the private pointer, except for
  2217. * the usage and max_buffers members during the configure_streams() call
  2218. * itself.
  2219. *
  2220. * If the stream is new, max_buffer, and private pointer fields of the
  2221. * stream structure will all be set to 0. The usage will be set to the
  2222. * consumer usage flags. The HAL device must set these fields before the
  2223. * configure_streams() call returns. These fields are then used by the
  2224. * framework and the platform gralloc module to allocate the gralloc
  2225. * buffers for each stream.
  2226. *
  2227. * Newly allocated buffers may be included in a capture request at any time
  2228. * by the framework. Once a gralloc buffer is returned to the framework
  2229. * with process_capture_result (and its respective release_fence has been
  2230. * signaled) the framework may free or reuse it at any time.
  2231. *
  2232. * ------------------------------------------------------------------------
  2233. *
  2234. * Preconditions:
  2235. *
  2236. * The framework will only call this method when no captures are being
  2237. * processed. That is, all results have been returned to the framework, and
  2238. * all in-flight input and output buffers have been returned and their
  2239. * release sync fences have been signaled by the HAL. The framework will not
  2240. * submit new requests for capture while the configure_streams() call is
  2241. * underway.
  2242. *
  2243. * Postconditions:
  2244. *
  2245. * The HAL device must configure itself to provide maximum possible output
  2246. * frame rate given the sizes and formats of the output streams, as
  2247. * documented in the camera device's static metadata.
  2248. *
  2249. * Performance requirements:
  2250. *
  2251. * This call is expected to be heavyweight and possibly take several hundred
  2252. * milliseconds to complete, since it may require resetting and
  2253. * reconfiguring the image sensor and the camera processing pipeline.
  2254. * Nevertheless, the HAL device should attempt to minimize the
  2255. * reconfiguration delay to minimize the user-visible pauses during
  2256. * application operational mode changes (such as switching from still
  2257. * capture to video recording).
  2258. *
  2259. * The HAL should return from this call in 500ms, and must return from this
  2260. * call in 1000ms.
  2261. *
  2262. * Return values:
  2263. *
  2264. * 0: On successful stream configuration
  2265. *
  2266. * -EINVAL: If the requested stream configuration is invalid. Some examples
  2267. * of invalid stream configurations include:
  2268. *
  2269. * - Including more than 1 input-capable stream (INPUT or
  2270. * BIDIRECTIONAL)
  2271. *
  2272. * - Not including any output-capable streams (OUTPUT or
  2273. * BIDIRECTIONAL)
  2274. *
  2275. * - Including streams with unsupported formats, or an unsupported
  2276. * size for that format.
  2277. *
  2278. * - Including too many output streams of a certain format.
  2279. *
  2280. * Note that the framework submitting an invalid stream
  2281. * configuration is not normal operation, since stream
  2282. * configurations are checked before configure. An invalid
  2283. * configuration means that a bug exists in the framework code, or
  2284. * there is a mismatch between the HAL's static metadata and the
  2285. * requirements on streams.
  2286. *
  2287. * -ENODEV: If there has been a fatal error and the device is no longer
  2288. * operational. Only close() can be called successfully by the
  2289. * framework after this error is returned.
  2290. */
  2291. int (*configure_streams)(const struct camera3_device *,
  2292. camera3_stream_configuration_t *stream_list);
  2293. /**
  2294. * register_stream_buffers:
  2295. *
  2296. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2297. *
  2298. * DEPRECATED. This will not be called and must be set to NULL.
  2299. *
  2300. * <= CAMERA_DEVICE_API_VERSION_3_1:
  2301. *
  2302. * Register buffers for a given stream with the HAL device. This method is
  2303. * called by the framework after a new stream is defined by
  2304. * configure_streams, and before buffers from that stream are included in a
  2305. * capture request. If the same stream is listed in a subsequent
  2306. * configure_streams() call, register_stream_buffers will _not_ be called
  2307. * again for that stream.
  2308. *
  2309. * The framework does not need to register buffers for all configured
  2310. * streams before it submits the first capture request. This allows quick
  2311. * startup for preview (or similar use cases) while other streams are still
  2312. * being allocated.
  2313. *
  2314. * This method is intended to allow the HAL device to map or otherwise
  2315. * prepare the buffers for later use. The buffers passed in will already be
  2316. * locked for use. At the end of the call, all the buffers must be ready to
  2317. * be returned to the stream. The buffer_set argument is only valid for the
  2318. * duration of this call.
  2319. *
  2320. * If the stream format was set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,
  2321. * the camera HAL should inspect the passed-in buffers here to determine any
  2322. * platform-private pixel format information.
  2323. *
  2324. * Performance requirements:
  2325. *
  2326. * This should be a non-blocking call. The HAL should return from this call
  2327. * in 1ms, and must return from this call in 5ms.
  2328. *
  2329. * Return values:
  2330. *
  2331. * 0: On successful registration of the new stream buffers
  2332. *
  2333. * -EINVAL: If the stream_buffer_set does not refer to a valid active
  2334. * stream, or if the buffers array is invalid.
  2335. *
  2336. * -ENOMEM: If there was a failure in registering the buffers. The framework
  2337. * must consider all the stream buffers to be unregistered, and can
  2338. * try to register again later.
  2339. *
  2340. * -ENODEV: If there is a fatal error, and the device is no longer
  2341. * operational. Only close() can be called successfully by the
  2342. * framework after this error is returned.
  2343. */
  2344. int (*register_stream_buffers)(const struct camera3_device *,
  2345. const camera3_stream_buffer_set_t *buffer_set);
  2346. /**********************************************************************
  2347. * Request creation and submission
  2348. */
  2349. /**
  2350. * construct_default_request_settings:
  2351. *
  2352. * Create capture settings for standard camera use cases.
  2353. *
  2354. * The device must return a settings buffer that is configured to meet the
  2355. * requested use case, which must be one of the CAMERA3_TEMPLATE_*
  2356. * enums. All request control fields must be included.
  2357. *
  2358. * The HAL retains ownership of this structure, but the pointer to the
  2359. * structure must be valid until the device is closed. The framework and the
  2360. * HAL may not modify the buffer once it is returned by this call. The same
  2361. * buffer may be returned for subsequent calls for the same template, or for
  2362. * other templates.
  2363. *
  2364. * Performance requirements:
  2365. *
  2366. * This should be a non-blocking call. The HAL should return from this call
  2367. * in 1ms, and must return from this call in 5ms.
  2368. *
  2369. * Return values:
  2370. *
  2371. * Valid metadata: On successful creation of a default settings
  2372. * buffer.
  2373. *
  2374. * NULL: In case of a fatal error. After this is returned, only
  2375. * the close() method can be called successfully by the
  2376. * framework.
  2377. */
  2378. const camera_metadata_t* (*construct_default_request_settings)(
  2379. const struct camera3_device *,
  2380. int type);
  2381. /**
  2382. * process_capture_request:
  2383. *
  2384. * Send a new capture request to the HAL. The HAL should not return from
  2385. * this call until it is ready to accept the next request to process. Only
  2386. * one call to process_capture_request() will be made at a time by the
  2387. * framework, and the calls will all be from the same thread. The next call
  2388. * to process_capture_request() will be made as soon as a new request and
  2389. * its associated buffers are available. In a normal preview scenario, this
  2390. * means the function will be called again by the framework almost
  2391. * instantly.
  2392. *
  2393. * The actual request processing is asynchronous, with the results of
  2394. * capture being returned by the HAL through the process_capture_result()
  2395. * call. This call requires the result metadata to be available, but output
  2396. * buffers may simply provide sync fences to wait on. Multiple requests are
  2397. * expected to be in flight at once, to maintain full output frame rate.
  2398. *
  2399. * The framework retains ownership of the request structure. It is only
  2400. * guaranteed to be valid during this call. The HAL device must make copies
  2401. * of the information it needs to retain for the capture processing. The HAL
  2402. * is responsible for waiting on and closing the buffers' fences and
  2403. * returning the buffer handles to the framework.
  2404. *
  2405. * The HAL must write the file descriptor for the input buffer's release
  2406. * sync fence into input_buffer->release_fence, if input_buffer is not
  2407. * NULL. If the HAL returns -1 for the input buffer release sync fence, the
  2408. * framework is free to immediately reuse the input buffer. Otherwise, the
  2409. * framework will wait on the sync fence before refilling and reusing the
  2410. * input buffer.
  2411. *
  2412. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2413. *
  2414. * The input/output buffers provided by the framework in each request
  2415. * may be brand new (having never before seen by the HAL).
  2416. *
  2417. * ------------------------------------------------------------------------
  2418. * Performance considerations:
  2419. *
  2420. * Handling a new buffer should be extremely lightweight and there should be
  2421. * no frame rate degradation or frame jitter introduced.
  2422. *
  2423. * This call must return fast enough to ensure that the requested frame
  2424. * rate can be sustained, especially for streaming cases (post-processing
  2425. * quality settings set to FAST). The HAL should return this call in 1
  2426. * frame interval, and must return from this call in 4 frame intervals.
  2427. *
  2428. * Return values:
  2429. *
  2430. * 0: On a successful start to processing the capture request
  2431. *
  2432. * -EINVAL: If the input is malformed (the settings are NULL when not
  2433. * allowed, there are 0 output buffers, etc) and capture processing
  2434. * cannot start. Failures during request processing should be
  2435. * handled by calling camera3_callback_ops_t.notify(). In case of
  2436. * this error, the framework will retain responsibility for the
  2437. * stream buffers' fences and the buffer handles; the HAL should
  2438. * not close the fences or return these buffers with
  2439. * process_capture_result.
  2440. *
  2441. * -ENODEV: If the camera device has encountered a serious error. After this
  2442. * error is returned, only the close() method can be successfully
  2443. * called by the framework.
  2444. *
  2445. */
  2446. int (*process_capture_request)(const struct camera3_device *,
  2447. camera3_capture_request_t *request);
  2448. /**********************************************************************
  2449. * Miscellaneous methods
  2450. */
  2451. /**
  2452. * get_metadata_vendor_tag_ops:
  2453. *
  2454. * Get methods to query for vendor extension metadata tag information. The
  2455. * HAL should fill in all the vendor tag operation methods, or leave ops
  2456. * unchanged if no vendor tags are defined.
  2457. *
  2458. * The definition of vendor_tag_query_ops_t can be found in
  2459. * system/media/camera/include/system/camera_metadata.h.
  2460. *
  2461. * >= CAMERA_DEVICE_API_VERSION_3_2:
  2462. * DEPRECATED. This function has been deprecated and should be set to
  2463. * NULL by the HAL. Please implement get_vendor_tag_ops in camera_common.h
  2464. * instead.
  2465. */
  2466. void (*get_metadata_vendor_tag_ops)(const struct camera3_device*,
  2467. vendor_tag_query_ops_t* ops);
  2468. /**
  2469. * dump:
  2470. *
  2471. * Print out debugging state for the camera device. This will be called by
  2472. * the framework when the camera service is asked for a debug dump, which
  2473. * happens when using the dumpsys tool, or when capturing a bugreport.
  2474. *
  2475. * The passed-in file descriptor can be used to write debugging text using
  2476. * dprintf() or write(). The text should be in ASCII encoding only.
  2477. *
  2478. * Performance requirements:
  2479. *
  2480. * This must be a non-blocking call. The HAL should return from this call
  2481. * in 1ms, must return from this call in 10ms. This call must avoid
  2482. * deadlocks, as it may be called at any point during camera operation.
  2483. * Any synchronization primitives used (such as mutex locks or semaphores)
  2484. * should be acquired with a timeout.
  2485. */
  2486. void (*dump)(const struct camera3_device *, int fd);
  2487. /**
  2488. * flush:
  2489. *
  2490. * Flush all currently in-process captures and all buffers in the pipeline
  2491. * on the given device. The framework will use this to dump all state as
  2492. * quickly as possible in order to prepare for a configure_streams() call.
  2493. *
  2494. * No buffers are required to be successfully returned, so every buffer
  2495. * held at the time of flush() (whether successfully filled or not) may be
  2496. * returned with CAMERA3_BUFFER_STATUS_ERROR. Note the HAL is still allowed
  2497. * to return valid (CAMERA3_BUFFER_STATUS_OK) buffers during this call,
  2498. * provided they are successfully filled.
  2499. *
  2500. * All requests currently in the HAL are expected to be returned as soon as
  2501. * possible. Not-in-process requests should return errors immediately. Any
  2502. * interruptible hardware blocks should be stopped, and any uninterruptible
  2503. * blocks should be waited on.
  2504. *
  2505. * More specifically, the HAL must follow below requirements for various cases:
  2506. *
  2507. * 1. For captures that are too late for the HAL to cancel/stop, and will be
  2508. * completed normally by the HAL; i.e. the HAL can send shutter/notify and
  2509. * process_capture_result and buffers as normal.
  2510. *
  2511. * 2. For pending requests that have not done any processing, the HAL must call notify
  2512. * CAMERA3_MSG_ERROR_REQUEST, and return all the output buffers with
  2513. * process_capture_result in the error state (CAMERA3_BUFFER_STATUS_ERROR).
  2514. * The HAL must not place the release fence into an error state, instead,
  2515. * the release fences must be set to the acquire fences passed by the framework,
  2516. * or -1 if they have been waited on by the HAL already. This is also the path
  2517. * to follow for any captures for which the HAL already called notify() with
  2518. * CAMERA3_MSG_SHUTTER but won't be producing any metadata/valid buffers for.
  2519. * After CAMERA3_MSG_ERROR_REQUEST, for a given frame, only process_capture_results with
  2520. * buffers in CAMERA3_BUFFER_STATUS_ERROR are allowed. No further notifys or
  2521. * process_capture_result with non-null metadata is allowed.
  2522. *
  2523. * 3. For partially completed pending requests that will not have all the output
  2524. * buffers or perhaps missing metadata, the HAL should follow below:
  2525. *
  2526. * 3.1. Call notify with CAMERA3_MSG_ERROR_RESULT if some of the expected result
  2527. * metadata (i.e. one or more partial metadata) won't be available for the capture.
  2528. *
  2529. * 3.2. Call notify with CAMERA3_MSG_ERROR_BUFFER for every buffer that won't
  2530. * be produced for the capture.
  2531. *
  2532. * 3.3 Call notify with CAMERA3_MSG_SHUTTER with the capture timestamp before
  2533. * any buffers/metadata are returned with process_capture_result.
  2534. *
  2535. * 3.4 For captures that will produce some results, the HAL must not call
  2536. * CAMERA3_MSG_ERROR_REQUEST, since that indicates complete failure.
  2537. *
  2538. * 3.5. Valid buffers/metadata should be passed to the framework as normal.
  2539. *
  2540. * 3.6. Failed buffers should be returned to the framework as described for case 2.
  2541. * But failed buffers do not have to follow the strict ordering valid buffers do,
  2542. * and may be out-of-order with respect to valid buffers. For example, if buffers
  2543. * A, B, C, D, E are sent, D and E are failed, then A, E, B, D, C is an acceptable
  2544. * return order.
  2545. *
  2546. * 3.7. For fully-missing metadata, calling CAMERA3_MSG_ERROR_RESULT is sufficient, no
  2547. * need to call process_capture_result with NULL metadata or equivalent.
  2548. *
  2549. * flush() should only return when there are no more outstanding buffers or
  2550. * requests left in the HAL. The framework may call configure_streams (as
  2551. * the HAL state is now quiesced) or may issue new requests.
  2552. *
  2553. * Note that it's sufficient to only support fully-succeeded and fully-failed result cases.
  2554. * However, it is highly desirable to support the partial failure cases as well, as it
  2555. * could help improve the flush call overall performance.
  2556. *
  2557. * Performance requirements:
  2558. *
  2559. * The HAL should return from this call in 100ms, and must return from this
  2560. * call in 1000ms. And this call must not be blocked longer than pipeline
  2561. * latency (see S7 for definition).
  2562. *
  2563. * Version information:
  2564. *
  2565. * only available if device version >= CAMERA_DEVICE_API_VERSION_3_1.
  2566. *
  2567. * Return values:
  2568. *
  2569. * 0: On a successful flush of the camera HAL.
  2570. *
  2571. * -EINVAL: If the input is malformed (the device is not valid).
  2572. *
  2573. * -ENODEV: If the camera device has encountered a serious error. After this
  2574. * error is returned, only the close() method can be successfully
  2575. * called by the framework.
  2576. */
  2577. int (*flush)(const struct camera3_device *);
  2578. /* reserved for future use */
  2579. void *reserved[8];
  2580. } camera3_device_ops_t;
  2581. /**********************************************************************
  2582. *
  2583. * Camera device definition
  2584. *
  2585. */
  2586. typedef struct camera3_device {
  2587. /**
  2588. * common.version must equal CAMERA_DEVICE_API_VERSION_3_0 to identify this
  2589. * device as implementing version 3.0 of the camera device HAL.
  2590. *
  2591. * Performance requirements:
  2592. *
  2593. * Camera open (common.module->common.methods->open) should return in 200ms, and must return
  2594. * in 500ms.
  2595. * Camera close (common.close) should return in 200ms, and must return in 500ms.
  2596. *
  2597. */
  2598. hw_device_t common;
  2599. camera3_device_ops_t *ops;
  2600. void *priv;
  2601. } camera3_device_t;
  2602. __END_DECLS
  2603. #endif /* #ifdef ANDROID_INCLUDE_CAMERA3_H */