referencia de estructura camera3_device_ops

configurar_flujos:

CAMERA_DEVICE_API_VERSION_3_0 solamente:

Restablezca el proceso de procesamiento del dispositivo de cámara HAL y configure nuevos flujos de entrada y salida. Esta llamada reemplaza cualquier configuración de transmisión existente con las transmisiones definidas en stream_list. Este método se llamará al menos una vez después de inicializar() antes de enviar una solicitud con process_capture_request() .

stream_list debe contener al menos un flujo con capacidad de salida y no puede contener más de un flujo con capacidad de entrada.

stream_list puede contener transmisiones que también están en el conjunto de transmisiones actualmente activo (de la llamada anterior a configure_stream()). Estas transmisiones ya tendrán valores válidos para el uso, max_buffers y el puntero privado.

Si dicha secuencia ya tiene sus buffers registrados, no se volverá a llamar a Register_stream_buffers() para la secuencia, y los buffers de la secuencia se pueden incluir inmediatamente en las solicitudes de entrada.

Si HAL necesita cambiar la configuración de transmisión para una transmisión existente debido a la nueva configuración, puede reescribir los valores de uso y/o max_buffers durante la llamada de configuración.

El marco detectará dicho cambio y luego reasignará los búferes de flujo y llamará a Register_stream_buffers() nuevamente antes de usar los búferes de ese flujo en una solicitud.

Si una secuencia actualmente activa no está incluida en stream_list, HAL puede eliminar de forma segura cualquier referencia a esa secuencia. No se reutilizará en una llamada posterior a configure() por parte del marco, y todos los buffers gralloc se liberarán después de que regrese la llamada a configure_streams() .

La estructura stream_list es propiedad del marco y no se puede acceder a ella una vez que se completa esta llamada. La dirección de una estructura individual camera3_stream_t seguirá siendo válida para el acceso de HAL hasta el final de la primera llamada configure_stream() que ya no incluye esa camera3_stream_t en el argumento stream_list. HAL no puede cambiar los valores en la estructura de flujo fuera del puntero privado, excepto los miembros use y max_buffers durante la llamada a configure_streams() .

Si la transmisión es nueva, los campos de uso, max_buffer y puntero privado de la estructura de la transmisión se establecerán en 0. El dispositivo HAL debe configurar estos campos antes de que regrese la llamada configure_streams() . Luego, el marco y el módulo gralloc de la plataforma utilizan estos campos para asignar los buffers gralloc para cada flujo.

Antes de que una nueva secuencia de este tipo pueda incluir sus buffers en una solicitud de captura, el marco llamará a Register_stream_buffers() con esa secuencia. Sin embargo, no es necesario que el marco registre buffers para todas las transmisiones antes de enviar una solicitud. Esto permite el inicio rápido de (por ejemplo) una secuencia de vista previa, con la asignación de otras secuencias más adelante o al mismo tiempo.

CAMERA_DEVICE_API_VERSION_3_1 solamente:

Restablezca el proceso de procesamiento del dispositivo de cámara HAL y configure nuevos flujos de entrada y salida. Esta llamada reemplaza cualquier configuración de transmisión existente con las transmisiones definidas en stream_list. Este método se llamará al menos una vez después de inicializar() antes de enviar una solicitud con process_capture_request() .

stream_list debe contener al menos un flujo con capacidad de salida y no puede contener más de un flujo con capacidad de entrada.

stream_list puede contener transmisiones que también están en el conjunto de transmisiones actualmente activo (de la llamada anterior a configure_stream()). Estas transmisiones ya tendrán valores válidos para el uso, max_buffers y el puntero privado.

Si dicha secuencia ya tiene sus buffers registrados, no se volverá a llamar a Register_stream_buffers() para la secuencia, y los buffers de la secuencia se pueden incluir inmediatamente en las solicitudes de entrada.

Si HAL necesita cambiar la configuración de transmisión para una transmisión existente debido a la nueva configuración, puede reescribir los valores de uso y/o max_buffers durante la llamada de configuración.

El marco detectará dicho cambio y luego reasignará los búferes de flujo y llamará a Register_stream_buffers() nuevamente antes de usar los búferes de ese flujo en una solicitud.

Si una secuencia actualmente activa no está incluida en stream_list, HAL puede eliminar de forma segura cualquier referencia a esa secuencia. No se reutilizará en una llamada posterior a configure() por parte del marco, y todos los buffers gralloc se liberarán después de que regrese la llamada a configure_streams() .

La estructura stream_list es propiedad del marco y no se puede acceder a ella una vez que se completa esta llamada. La dirección de una estructura individual camera3_stream_t seguirá siendo válida para el acceso de HAL hasta el final de la primera llamada configure_stream() que ya no incluye esa camera3_stream_t en el argumento stream_list. HAL no puede cambiar los valores en la estructura de flujo fuera del puntero privado, excepto los miembros use y max_buffers durante la llamada a configure_streams() .

Si la transmisión es nueva, los campos max_buffer y de puntero privado de la estructura de la transmisión se establecerán en 0. El uso se establecerá según los indicadores de uso del consumidor. El dispositivo HAL debe configurar estos campos antes de que regrese la llamada configure_streams() . Luego, el marco y el módulo gralloc de la plataforma utilizan estos campos para asignar los buffers gralloc para cada flujo.

Antes de que una nueva secuencia de este tipo pueda incluir sus buffers en una solicitud de captura, el marco llamará a Register_stream_buffers() con esa secuencia. Sin embargo, no es necesario que el marco registre buffers para todas las transmisiones antes de enviar una solicitud. Esto permite el inicio rápido de (por ejemplo) una secuencia de vista previa, con la asignación de otras secuencias más adelante o al mismo tiempo.

>= CAMERA_DEVICE_API_VERSION_3_2:

Restablezca el proceso de procesamiento del dispositivo de cámara HAL y configure nuevos flujos de entrada y salida. Esta llamada reemplaza cualquier configuración de transmisión existente con las transmisiones definidas en stream_list. Este método se llamará al menos una vez después de inicializar() antes de enviar una solicitud con process_capture_request() .

stream_list debe contener al menos un flujo con capacidad de salida y no puede contener más de un flujo con capacidad de entrada.

stream_list puede contener transmisiones que también están en el conjunto de transmisiones actualmente activo (de la llamada anterior a configure_stream()). Estas transmisiones ya tendrán valores válidos para el uso, max_buffers y el puntero privado.

Si HAL necesita cambiar la configuración de transmisión para una transmisión existente debido a la nueva configuración, puede reescribir los valores de uso y/o max_buffers durante la llamada de configuración.

El marco detectará dicho cambio y luego podrá reasignar los buffers de flujo antes de usar buffers de ese flujo en una solicitud.

Si una secuencia actualmente activa no está incluida en stream_list, HAL puede eliminar de forma segura cualquier referencia a esa secuencia. No se reutilizará en una llamada posterior a configure() por parte del marco, y todos los buffers gralloc se liberarán después de que regrese la llamada a configure_streams() .

La estructura stream_list es propiedad del marco y no se puede acceder a ella una vez que se completa esta llamada. La dirección de una estructura individual camera3_stream_t seguirá siendo válida para el acceso de HAL hasta el final de la primera llamada configure_stream() que ya no incluye esa camera3_stream_t en el argumento stream_list. HAL no puede cambiar los valores en la estructura de flujo fuera del puntero privado, excepto los miembros use y max_buffers durante la llamada a configure_streams() .

Si la transmisión es nueva, los campos max_buffer y de puntero privado de la estructura de la transmisión se establecerán en 0. El uso se establecerá según los indicadores de uso del consumidor. El dispositivo HAL debe configurar estos campos antes de que regrese la llamada configure_streams() . Luego, el marco y el módulo gralloc de la plataforma utilizan estos campos para asignar los buffers gralloc para cada flujo.

El marco puede incluir buffers recién asignados en una solicitud de captura en cualquier momento. Una vez que un búfer gralloc se devuelve al marco con Process_capture_result (y se ha señalado su respectivo release_fence), el marco puede liberarlo o reutilizarlo en cualquier momento.

Condiciones previas:

El marco solo llamará a este método cuando no se estén procesando capturas. Es decir, todos los resultados se han devuelto al marco, y se han devuelto todos los buffers de entrada y salida en vuelo y el HAL ha señalado sus límites de sincronización de liberación. El marco no enviará nuevas solicitudes de captura mientras la llamada configure_streams() esté en curso.

Poscondiciones:

El dispositivo HAL debe configurarse para proporcionar la máxima velocidad de fotogramas de salida posible dados los tamaños y formatos de los flujos de salida, como se documenta en los metadatos estáticos del dispositivo de la cámara.

Requisitos de desempeño:

Se espera que esta llamada sea pesada y posiblemente tarde varios cientos de milisegundos en completarse, ya que puede requerir restablecer y reconfigurar el sensor de imagen y el proceso de procesamiento de la cámara. Sin embargo, el dispositivo HAL debe intentar minimizar el retraso de reconfiguración para minimizar las pausas visibles para el usuario durante los cambios del modo operativo de la aplicación (como cambiar de captura de imágenes fijas a grabación de video).

El HAL debería regresar de esta llamada en 500 ms y debe regresar de esta llamada en 1000 ms.

Valores de retorno:

0: en configuración de transmisión exitosa

-EINVAL: Si la configuración de flujo solicitada no es válida. Algunos ejemplos de configuraciones de transmisión no válidas incluyen:

• Incluyendo más de 1 flujo con capacidad de entrada (ENTRADA o BIDIRECCIONAL)
• Sin incluir transmisiones con capacidad de salida (SALIDA o BIDIRECCIONAL)
• Incluyendo transmisiones con formatos no admitidos o un tamaño no admitido para ese formato.
• Incluir demasiados flujos de salida de un formato determinado.
• Configuración de rotación no admitida (solo se aplica a dispositivos con versión >= CAMERA_DEVICE_API_VERSION_3_3)
• Los tamaños/formatos de transmisión no satisfacen los requisitos de camera3_stream_configuration_t-> Operation_mode para el modo no NORMAL, o el HAL no admite el modo de operación solicitado. (solo aplica a dispositivos con versión >= CAMERA_DEVICE_API_VERSION_3_3)

Tenga en cuenta que el marco que envía una configuración de transmisión no válida no es una operación normal, ya que las configuraciones de la transmisión se verifican antes de la configuración. Una configuración no válida significa que existe un error en el código del marco o que hay una discrepancia entre los metadatos estáticos de HAL y los requisitos de las transmisiones.

-ENODEV: Si ha habido un error fatal y el dispositivo ya no está operativo. El marco solo puede llamar exitosamente a close() después de que se devuelve este error.

Definición en la línea 2769 del archivo camera3.h .

construct_default_request_settings:

Cree configuraciones de captura para casos de uso de cámara estándar.

El dispositivo debe devolver un búfer de configuración configurado para cumplir con el caso de uso solicitado, que debe ser una de las enumeraciones CAMERA3_TEMPLATE_*. Se deben incluir todos los campos de control de solicitudes.

HAL conserva la propiedad de esta estructura, pero el puntero a la estructura debe ser válido hasta que se cierre el dispositivo. El marco y HAL no pueden modificar el búfer una vez que esta llamada lo devuelve. Se puede devolver el mismo búfer para llamadas posteriores para la misma plantilla o para otras plantillas.

Requisitos de desempeño:

Esta debería ser una llamada sin bloqueo. El HAL debería regresar de esta llamada en 1 ms y debe regresar de esta llamada en 5 ms.

Valores de retorno:

Metadatos válidos: tras la creación exitosa de un búfer de configuración predeterminado.

NULL: En caso de un error fatal. Una vez devuelto esto, el marco solo puede llamar con éxito al método close().

Definición en la línea 2859 del archivo camera3.h .

vertedero:

Imprima el estado de depuración del dispositivo de la cámara. El marco llamará a esto cuando se solicite al servicio de la cámara un volcado de depuración, lo que ocurre cuando se utiliza la herramienta dumpsys o cuando se captura un informe de error.

El descriptor de archivo pasado se puede usar para escribir texto de depuración usando dprintf() o write(). El texto debe estar únicamente en codificación ASCII.

Requisitos de desempeño:

Esta debe ser una llamada sin bloqueo. El HAL debería regresar de esta llamada en 1 ms, debe regresar de esta llamada en 10 ms. Esta llamada debe evitar interbloqueos, ya que puede ser llamada en cualquier momento durante el funcionamiento de la cámara. Cualquier primitiva de sincronización utilizada (como bloqueos mutex o semáforos) debe adquirirse con un tiempo de espera.

Definición en la línea 2971 del archivo camera3.h .

enjuagar:

Vacíe todas las capturas actualmente en proceso y todos los buffers en proceso en el dispositivo dado. El marco usará esto para volcar todo el estado lo más rápido posible para prepararse para una llamada a configure_streams() .

No se requiere que los buffers se devuelvan exitosamente, por lo que cada buffer retenido en el momento de vaciar() (ya sea que se haya llenado exitosamente o no) puede devolverse con CAMERA3_BUFFER_STATUS_ERROR. Tenga en cuenta que HAL todavía puede devolver buffers válidos (CAMERA3_BUFFER_STATUS_OK) durante esta llamada, siempre que se llenen correctamente.

Se espera que todas las solicitudes actualmente en HAL sean devueltas lo antes posible. Las solicitudes que no están en proceso deberían devolver errores inmediatamente. Se deben detener todos los bloques de hardware interrumpibles y se debe esperar a los bloques ininterrumpibles.

Flush() se puede llamar simultáneamente a Process_capture_request() , con la expectativa de que Process_capture_request regrese rápidamente y la solicitud enviada en esa llamada Process_capture_request se trate como todas las demás solicitudes en curso. Debido a problemas de concurrencia, es posible que desde el punto de vista de HAL, se pueda iniciar una llamada a Process_capture_request() después de que se haya invocado Flush pero aún no haya regresado. Si dicha llamada ocurre antes de que fluya() regrese, HAL debe tratar la nueva solicitud de captura como otras solicitudes pendientes en curso (consulte el punto 4 a continuación).

Más específicamente, el HAL debe seguir los siguientes requisitos para varios casos:

1. Para capturas que son demasiado tarde para que HAL las cancele o detenga, y que HAL las completará normalmente; es decir, HAL puede enviar obturador/notificar y procesar_captura_resultado y buffers como de costumbre.
2. Para las solicitudes pendientes que no han realizado ningún procesamiento, HAL debe llamar a notificar a CAMERA3_MSG_ERROR_REQUEST y devolver todos los búferes de salida con process_capture_result en estado de error (CAMERA3_BUFFER_STATUS_ERROR). HAL no debe colocar el límite de liberación en un estado de error; en cambio, los límites de liberación deben configurarse en los límites de adquisición pasados ​​por el marco, o -1 si HAL ya los ha esperado. Este también es el camino a seguir para cualquier captura para la cual HAL ya llamó a notify() con CAMERA3_MSG_SHUTTER pero no producirá ningún metadato/búfer válido. Después de CAMERA3_MSG_ERROR_REQUEST, para un fotograma determinado, solo se permiten Process_capture_results con buffers en CAMERA3_BUFFER_STATUS_ERROR. No se permiten más notificaciones ni Process_capture_result con metadatos no nulos.

3. Para solicitudes pendientes parcialmente completadas que no tendrán todos los buffers de salida o quizás falten metadatos, el HAL debe seguir lo siguiente:

   3.1. Llame a notificar con CAMERA3_MSG_ERROR_RESULT si algunos de los metadatos del resultado esperado (es decir, uno o más metadatos parciales) no estarán disponibles para la captura.

   3.2. Llame a notificar con CAMERA3_MSG_ERROR_BUFFER para cada búfer que no se producirá para la captura.

   3.3 Llame a notificar con CAMERA3_MSG_SHUTTER con la marca de tiempo de captura antes de que se devuelvan los búfer/metadatos con process_capture_result.

   3.4 Para capturas que producirán algunos resultados, el HAL no debe llamar a CAMERA3_MSG_ERROR_REQUEST, ya que eso indica una falla total.

   3.5. Los buffers/metadatos válidos deben pasarse al marco como de costumbre.

   3.6. Los búferes fallidos deben devolverse al marco como se describe para el caso 2. Pero los búferes fallidos no tienen que seguir el orden estricto que siguen los búferes válidos y pueden estar desordenados con respecto a los búferes válidos. Por ejemplo, si se envían los buffers A, B, C, D, E, D y E fallan, entonces A, E, B, D, C es una orden de devolución aceptable.

   3.7. Para metadatos que faltan por completo, llamar a CAMERA3_MSG_ERROR_RESULT es suficiente; no es necesario llamar a Process_capture_result con metadatos NULL o equivalente.

4. Si se invoca una descarga() mientras una invocación de Process_capture_request() está activa, esa llamada de proceso debería regresar lo antes posible. Además, si se realiza una llamada a Process_capture_request() después de que se haya invocado a Flush() pero antes de que Flush() haya regresado, la solicitud de captura proporcionada por la última llamada a Process_capture_request debe tratarse como una solicitud pendiente en el caso #2 anterior.

flush() solo debería regresar cuando no queden más buffers o solicitudes pendientes en el HAL. El marco puede llamar a configure_streams (ya que el estado HAL ahora está inactivo) o puede emitir nuevas solicitudes.

Tenga en cuenta que es suficiente admitir únicamente casos de resultados totalmente exitosos y totalmente fallidos. Sin embargo, es muy deseable admitir también los casos de falla parcial, ya que podría ayudar a mejorar el rendimiento general de la llamada de descarga.

Requisitos de desempeño:

El HAL debería regresar de esta llamada en 100 ms y debe regresar de esta llamada en 1000 ms. Y esta llamada no debe bloquearse por más tiempo que la latencia de canalización (consulte S7 para conocer la definición).

Información de versión:

solo disponible si la versión del dispositivo >= CAMERA_DEVICE_API_VERSION_3_1.

Valores de retorno:

0: En caso de un lavado exitoso de la cámara HAL.

-EINVAL: Si la entrada está mal formada (el dispositivo no es válido).

-ENODEV: Si el dispositivo de la cámara ha encontrado un error grave. Después de que se devuelve este error, el marco solo puede llamar con éxito al método close().

Definición en la línea 3077 del archivo camera3.h .

get_metadata_vendor_tag_ops:

Obtenga métodos para consultar información de etiquetas de metadatos de extensión del proveedor. La HAL debe completar todos los métodos de operación de etiquetas de proveedor o dejar las operaciones sin cambios si no se definen etiquetas de proveedor.

La definición de seller_tag_query_ops_t se puede encontrar en system/media/camera/include/system/camera_metadata.h.

>= CAMERA_DEVICE_API_VERSION_3_2: DESPRECADO. Esta función ha quedado obsoleta y HAL debe establecerla en NULL. Implemente get_vendor_tag_ops en camera_common.h en su lugar.

Definición en la línea 2950 del archivo camera3.h .

inicializar:

Inicialización única para pasar punteros de función de devolución de llamada del marco a HAL. Se llamará una vez después de una llamada open() exitosa, antes de que se llame a cualquier otra función en la estructura camera3_device_ops .

Requisitos de desempeño:

Esta debería ser una llamada sin bloqueo. El HAL debería regresar de esta llamada en 5 ms y debe regresar de esta llamada en 10 ms.

Valores de retorno:

0: en caso de inicialización exitosa

-ENODEV: Si falla la inicialización. Después de esto, el marco solo puede llamar exitosamente a close().

Definición en la línea 2530 del archivo camera3.h .

solicitud_captura_proceso:

Envíe una nueva solicitud de captura al HAL. El HAL no debe regresar de esta llamada hasta que esté listo para aceptar la siguiente solicitud para procesar. El marco solo realizará una llamada a Process_capture_request() a la vez, y todas las llamadas serán del mismo hilo. La próxima llamada a Process_capture_request() se realizará tan pronto como estén disponibles una nueva solicitud y sus buffers asociados. En un escenario de vista previa normal, esto significa que el marco volverá a llamar a la función casi instantáneamente.

El procesamiento de solicitudes real es asincrónico, y HAL devuelve los resultados de la captura a través de la llamada Process_capture_result(). Esta llamada requiere que los metadatos del resultado estén disponibles, pero los buffers de salida pueden simplemente proporcionar barreras de sincronización para esperar. Se espera que haya varias solicitudes en curso a la vez para mantener la velocidad de fotogramas de salida completa.

El marco conserva la propiedad de la estructura de la solicitud. Sólo se garantiza que será válido durante esta llamada. El dispositivo HAL debe realizar copias de la información que necesita retener para el procesamiento de captura. HAL es responsable de esperar y cerrar las barreras de los buffers y de devolver los identificadores del buffer al marco.

HAL debe escribir el descriptor de archivo para el límite de sincronización de liberación del búfer de entrada en input_buffer->release_fence, si input_buffer no es NULL. Si HAL devuelve -1 para el límite de sincronización de liberación del búfer de entrada, el marco puede reutilizar inmediatamente el búfer de entrada. De lo contrario, el marco esperará en la barrera de sincronización antes de rellenar y reutilizar el búfer de entrada.

>= CAMERA_DEVICE_API_VERSION_3_2:

Los buffers de entrada/salida proporcionados por el marco en cada solicitud pueden ser completamente nuevos (nunca antes vistos por HAL).

Consideraciones de rendimiento:

El manejo de un nuevo búfer debe ser extremadamente liviano y no debe haber degradación de la velocidad de fotogramas ni introducción de fluctuaciones de fotogramas.

Esta llamada debe regresar lo suficientemente rápido para garantizar que se pueda mantener la velocidad de fotogramas solicitada, especialmente para los casos de transmisión (configuraciones de calidad de posprocesamiento establecidas en RÁPIDO). El HAL debe devolver esta llamada en intervalos de 1 cuadro y debe regresar de esta llamada en intervalos de 4 cuadros.

Valores de retorno:

0: en un inicio exitoso del procesamiento de la solicitud de captura

-EINVAL: si la entrada tiene un formato incorrecto (la configuración es NULL cuando no está permitida, hay 0 buffers de salida, etc.) y el procesamiento de captura no puede iniciarse. Las fallas durante el procesamiento de solicitudes deben manejarse llamando a camera3_callback_ops_t.notify() . En caso de este error, el marco seguirá siendo responsable de las barreras de los buffers de flujo y los identificadores del buffer; HAL no debe cerrar las barreras ni devolver estos buffers con Process_capture_result.

-ENODEV: Si el dispositivo de la cámara ha encontrado un error grave. Después de que se devuelve este error, el marco solo puede llamar con éxito al método close().

Definición en la línea 2928 del archivo camera3.h .

registrar_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

OBSOLETO. Esto no será llamado y debe establecerse en NULL.

<= CAMERA_DEVICE_API_VERSION_3_1:

Registre buffers para una secuencia determinada con el dispositivo HAL. El marco llama a este método después de que configure_streams define una nueva secuencia y antes de que los buffers de esa secuencia se incluyan en una solicitud de captura. Si la misma secuencia aparece en una llamada posterior a configure_streams() , no se volverá a llamar a Register_stream_buffers para esa secuencia.

El marco no necesita registrar buffers para todas las transmisiones configuradas antes de enviar la primera solicitud de captura. Esto permite un inicio rápido para la vista previa (o casos de uso similares) mientras aún se están asignando otras transmisiones.

Este método está destinado a permitir que el dispositivo HAL mapee o prepare de otro modo los buffers para su uso posterior. Los buffers pasados ​​ya estarán bloqueados para su uso. Al final de la llamada, todos los buffers deben estar listos para ser devueltos a la secuencia. El argumento buffer_set solo es válido mientras dure esta llamada.

Si el formato de transmisión se configuró en HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, la cámara HAL debe inspeccionar los buffers pasados ​​aquí para determinar cualquier información de formato de píxel privado de la plataforma.

Requisitos de desempeño:

Esta debería ser una llamada sin bloqueo. El HAL debería regresar de esta llamada en 1 ms y debe regresar de esta llamada en 5 ms.

Valores de retorno:

0: tras el registro exitoso de los nuevos buffers de flujo

-EINVAL: si stream_buffer_set no hace referencia a una secuencia activa válida, o si la matriz de buffers no es válida.

-ENOMEM: Si hubo un fallo en el registro de los buffers. El marco debe considerar que todos los buffers de flujo no están registrados y puede intentar registrarse nuevamente más tarde.

-ENODEV: Si hay un error fatal y el dispositivo ya no está operativo. El marco solo puede llamar exitosamente a close() después de que se devuelva este error.

Definición en la línea 2823 del archivo camera3.h .

Definición en la línea 3080 del archivo camera3.h .