Referência de estrutura camera3_device_ops
#include < camera3.h >
Campos de dados | |
| interno(* | inicializar )(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
| interno(* | configure_streams )(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
| interno(* | registrar_stream_buffers )(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
| const camera_metadata_t *(* | construct_default_request_settings )(const struct camera3_device *, tipo int) |
| interno(* | process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request) |
| vazio(* | get_metadata_vendor_tag_ops )(const struct camera3_device *, vendor_tag_query_ops_t *ops) |
| vazio(* | dump )(const struct camera3_device *, int fd) |
| interno(* | flush )(const struct camera3_device *) |
| vazio * | reservado [8] |
Descrição detalhada
Documentação de campo
| int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
configure_streams:
Somente CAMERA_DEVICE_API_VERSION_3_0:
Redefina o pipeline de processamento do dispositivo de câmera HAL e configure novos fluxos de entrada e saída. Esta chamada substitui qualquer configuração de fluxo existente pelos fluxos definidos em stream_list. Este método será chamado pelo menos uma vez após inicializar() antes que uma solicitação seja enviada com process_capture_request() .
O stream_list deve conter pelo menos um fluxo com capacidade de saída e não pode conter mais de um fluxo com capacidade de entrada.
O stream_list pode conter streams que também estão no conjunto de streams atualmente ativo (da chamada anterior para configure_stream()). Esses fluxos já terão valores válidos para uso, max_buffers e ponteiro privado.
Se tal fluxo já tiver seus buffers registrados, register_stream_buffers() não será chamado novamente para o fluxo e os buffers do fluxo poderão ser incluídos imediatamente nas solicitações de entrada.
Se o HAL precisar alterar a configuração de fluxo para um fluxo existente devido à nova configuração, ele poderá reescrever os valores de uso e/ou max_buffers durante a chamada de configuração.
A estrutura detectará tal mudança e, em seguida, realocará os buffers de fluxo e chamará Register_stream_buffers() novamente antes de usar buffers desse fluxo em uma solicitação.
Se um fluxo atualmente ativo não estiver incluído em stream_list, o HAL poderá remover com segurança quaisquer referências a esse fluxo. Ele não será reutilizado em uma chamada configure() posterior pela estrutura, e todos os buffers gralloc para ele serão liberados após o retorno da chamada configure_streams() .
A estrutura stream_list pertence à estrutura e não pode ser acessada após a conclusão desta chamada. O endereço de uma estrutura camera3_stream_t individual permanecerá válido para acesso pelo HAL até o final da primeira chamada configure_stream() que não inclui mais essa camera3_stream_t no argumento stream_list. O HAL não pode alterar valores na estrutura de fluxo fora do ponteiro privado, exceto para os membros de uso e max_buffers durante a própria chamada configure_streams() .
Se o fluxo for novo, os campos de uso, max_buffer e ponteiro privado da estrutura do fluxo serão todos definidos como 0. O dispositivo HAL deve definir esses campos antes que a chamada configure_streams() retorne. Esses campos são então usados pela estrutura e pelo módulo gralloc da plataforma para alocar os buffers gralloc para cada fluxo.
Antes que esse novo fluxo possa ter seus buffers incluídos em uma solicitação de captura, a estrutura chamará register_stream_buffers() com esse fluxo. Entretanto, a estrutura não é obrigada a registrar buffers para todos os fluxos antes de enviar uma solicitação. Isso permite a inicialização rápida (por exemplo) de um stream de visualização, com a alocação para outros streams acontecendo posteriormente ou simultaneamente.
Apenas CAMERA_DEVICE_API_VERSION_3_1:
Redefina o pipeline de processamento do dispositivo de câmera HAL e configure novos fluxos de entrada e saída. Esta chamada substitui qualquer configuração de fluxo existente pelos fluxos definidos em stream_list. Este método será chamado pelo menos uma vez após inicializar() antes que uma solicitação seja enviada com process_capture_request() .
O stream_list deve conter pelo menos um fluxo com capacidade de saída e não pode conter mais de um fluxo com capacidade de entrada.
O stream_list pode conter streams que também estão no conjunto de streams atualmente ativo (da chamada anterior para configure_stream()). Esses fluxos já terão valores válidos para uso, max_buffers e ponteiro privado.
Se tal fluxo já tiver seus buffers registrados, register_stream_buffers() não será chamado novamente para o fluxo e os buffers do fluxo poderão ser incluídos imediatamente nas solicitações de entrada.
Se o HAL precisar alterar a configuração de fluxo para um fluxo existente devido à nova configuração, ele poderá reescrever os valores de uso e/ou max_buffers durante a chamada de configuração.
A estrutura detectará tal mudança e, em seguida, realocará os buffers de fluxo e chamará Register_stream_buffers() novamente antes de usar buffers desse fluxo em uma solicitação.
Se um fluxo atualmente ativo não estiver incluído em stream_list, o HAL poderá remover com segurança quaisquer referências a esse fluxo. Ele não será reutilizado em uma chamada configure() posterior pela estrutura, e todos os buffers gralloc para ele serão liberados após o retorno da chamada configure_streams() .
A estrutura stream_list pertence à estrutura e não pode ser acessada após a conclusão desta chamada. O endereço de uma estrutura camera3_stream_t individual permanecerá válido para acesso pelo HAL até o final da primeira chamada configure_stream() que não inclui mais essa camera3_stream_t no argumento stream_list. O HAL não pode alterar valores na estrutura de fluxo fora do ponteiro privado, exceto para os membros de uso e max_buffers durante a própria chamada configure_streams() .
Se o fluxo for novo, os campos max_buffer e ponteiro privado da estrutura do fluxo serão todos definidos como 0. O uso será definido para os sinalizadores de uso do consumidor. O dispositivo HAL deve definir esses campos antes que a chamada configure_streams() retorne. Esses campos são então usados pela estrutura e pelo módulo gralloc da plataforma para alocar os buffers gralloc para cada fluxo.
Antes que esse novo fluxo possa ter seus buffers incluídos em uma solicitação de captura, a estrutura chamará register_stream_buffers() com esse fluxo. Entretanto, a estrutura não é obrigada a registrar buffers para todos os fluxos antes de enviar uma solicitação. Isso permite a inicialização rápida (por exemplo) de um stream de visualização, com a alocação para outros streams acontecendo posteriormente ou simultaneamente.
>= CAMERA_DEVICE_API_VERSION_3_2:
Redefina o pipeline de processamento do dispositivo de câmera HAL e configure novos fluxos de entrada e saída. Esta chamada substitui qualquer configuração de fluxo existente pelos fluxos definidos em stream_list. Este método será chamado pelo menos uma vez após inicializar() antes que uma solicitação seja enviada com process_capture_request() .
O stream_list deve conter pelo menos um fluxo com capacidade de saída e não pode conter mais de um fluxo com capacidade de entrada.
O stream_list pode conter streams que também estão no conjunto de streams atualmente ativo (da chamada anterior para configure_stream()). Esses fluxos já terão valores válidos para uso, max_buffers e ponteiro privado.
Se o HAL precisar alterar a configuração de fluxo para um fluxo existente devido à nova configuração, ele poderá reescrever os valores de uso e/ou max_buffers durante a chamada de configuração.
A estrutura detectará tal alteração e poderá então realocar os buffers de fluxo antes de usar buffers desse fluxo em uma solicitação.
Se um fluxo atualmente ativo não estiver incluído em stream_list, o HAL poderá remover com segurança quaisquer referências a esse fluxo. Ele não será reutilizado em uma chamada configure() posterior pela estrutura, e todos os buffers gralloc para ele serão liberados após o retorno da chamada configure_streams() .
A estrutura stream_list pertence à estrutura e não pode ser acessada após a conclusão desta chamada. O endereço de uma estrutura camera3_stream_t individual permanecerá válido para acesso pelo HAL até o final da primeira chamada configure_stream() que não inclui mais aquela camera3_stream_t no argumento stream_list. O HAL não pode alterar valores na estrutura de fluxo fora do ponteiro privado, exceto para os membros de uso e max_buffers durante a própria chamada configure_streams() .
Se o fluxo for novo, os campos max_buffer e ponteiro privado da estrutura do fluxo serão todos definidos como 0. O uso será definido para os sinalizadores de uso do consumidor. O dispositivo HAL deve definir esses campos antes que a chamada configure_streams() retorne. Esses campos são então usados pela estrutura e pelo módulo gralloc da plataforma para alocar os buffers gralloc para cada fluxo.
Buffers recém-alocados podem ser incluídos em uma solicitação de captura a qualquer momento pela estrutura. Uma vez que um buffer gralloc é retornado ao framework com process_capture_result (e seu respectivo release_fence foi sinalizado) o framework pode liberá-lo ou reutilizá-lo a qualquer momento.
Pré-condições:
A estrutura só chamará esse método quando nenhuma captura estiver sendo processada. Ou seja, todos os resultados foram retornados à estrutura, e todos os buffers de entrada e saída em voo foram retornados e suas cercas de sincronização de liberação foram sinalizadas pelo HAL. O framework não enviará novas solicitações de captura enquanto a chamada configure_streams() estiver em andamento.
Pós-condições:
O dispositivo HAL deve se configurar para fornecer a taxa de quadros de saída máxima possível, considerando os tamanhos e formatos dos fluxos de saída, conforme documentado nos metadados estáticos do dispositivo da câmera.
Requisitos de desempenho:
Espera-se que esta chamada seja pesada e possivelmente leve várias centenas de milissegundos para ser concluída, pois pode exigir a reinicialização e reconfiguração do sensor de imagem e do pipeline de processamento da câmera. No entanto, o dispositivo HAL deve tentar minimizar o atraso de reconfiguração para minimizar as pausas visíveis ao usuário durante as alterações do modo operacional do aplicativo (como mudar de captura estática para gravação de vídeo).
O HAL deverá retornar desta chamada em 500ms, e deverá retornar desta chamada em 1000ms.
Valores de retorno:
0: Na configuração de fluxo bem-sucedida
-EINVAL: Se a configuração de fluxo solicitada for inválida. Alguns exemplos de configurações de stream inválidas incluem:
- Incluindo mais de um fluxo com capacidade de entrada (INPUT ou BIDIRECTIONAL)
- Não incluindo quaisquer fluxos com capacidade de saída (SAÍDA ou BIDIRECIONAL)
- Incluindo streams com formatos não suportados ou um tamanho não suportado para esse formato.
- Incluindo muitos fluxos de saída de um determinado formato.
- Configuração de rotação não suportada (aplica-se apenas a dispositivos com versão >= CAMERA_DEVICE_API_VERSION_3_3)
- Os tamanhos/formatos de fluxo não atendem aos requisitos de camera3_stream_configuration_t->operation_mode para o modo não NORMAL ou o modo de operação solicitado não é suportado pelo HAL. (aplica-se apenas a dispositivos com versão >= CAMERA_DEVICE_API_VERSION_3_3)
Observe que a estrutura que envia uma configuração de fluxo inválida não é uma operação normal, pois as configurações de fluxo são verificadas antes da configuração. Uma configuração inválida significa que existe um bug no código da estrutura ou que há uma incompatibilidade entre os metadados estáticos do HAL e os requisitos nos fluxos.
-ENODEV: Se ocorreu um erro fatal e o dispositivo não está mais operacional. Somente close() pode ser chamado com sucesso pela estrutura após esse erro ser retornado.
| const camera_metadata_t *(* construct_default_request_settings)(const struct camera3_device *, tipo int) |
construct_default_request_settings:
Crie configurações de captura para casos de uso de câmera padrão.
O dispositivo deve retornar um buffer de configurações configurado para atender ao caso de uso solicitado, que deve ser um dos enums CAMERA3_TEMPLATE_*. Todos os campos de controle de solicitação devem ser incluídos.
O HAL retém a propriedade desta estrutura, mas o ponteiro para a estrutura deve ser válido até que o dispositivo seja fechado. A estrutura e o HAL não podem modificar o buffer depois que ele for retornado por esta chamada. O mesmo buffer pode ser retornado para chamadas subsequentes para o mesmo modelo ou para outros modelos.
Requisitos de desempenho:
Esta deve ser uma chamada sem bloqueio. O HAL deverá retornar desta chamada em 1ms, e deverá retornar desta chamada em 5ms.
Valores de retorno:
Metadados válidos: na criação bem-sucedida de um buffer de configurações padrão.
NULL: Em caso de erro fatal. Depois que isso for retornado, apenas o método close() poderá ser chamado com sucesso pela estrutura.
| void(* dump)(const struct camera3_device *, int fd) |
jogar fora:
Imprima o estado de depuração do dispositivo da câmera. Ele será chamado pelo framework quando for solicitado ao serviço de câmera um despejo de depuração, o que acontece ao usar a ferramenta dumpsys ou ao capturar um relatório de bug.
O descritor de arquivo passado pode ser usado para escrever texto de depuração usando dprintf() ou write(). O texto deve estar apenas em codificação ASCII.
Requisitos de desempenho:
Esta deve ser uma chamada sem bloqueio. O HAL deverá retornar desta chamada em 1ms, deverá retornar desta chamada em 10ms. Esta chamada deve evitar deadlocks, pois pode ser chamada a qualquer momento durante a operação da câmera. Quaisquer primitivas de sincronização usadas (como bloqueios mutex ou semáforos) devem ser adquiridas com um tempo limite.
| int(*flush)(const struct camera3_device *) |
rubor:
Libera todas as capturas atualmente em processo e todos os buffers no pipeline no dispositivo determinado. A estrutura usará isso para despejar todos os estados o mais rápido possível, a fim de se preparar para uma chamada configure_streams() .
Nenhum buffer é necessário para ser retornado com sucesso, portanto, cada buffer mantido no momento de flush() (preenchido com sucesso ou não) pode ser retornado com CAMERA3_BUFFER_STATUS_ERROR. Observe que o HAL ainda pode retornar buffers válidos (CAMERA3_BUFFER_STATUS_OK) durante esta chamada, desde que sejam preenchidos com sucesso.
Espera-se que todas as solicitações atualmente no HAL sejam retornadas o mais rápido possível. As solicitações que não estão em processo devem retornar erros imediatamente. Quaisquer blocos de hardware interrompíveis devem ser interrompidos e quaisquer blocos ininterruptos devem ser aguardados.
flush() pode ser chamado simultaneamente para process_capture_request() , com a expectativa de que process_capture_request retornará rapidamente e a solicitação enviada nessa chamada process_capture_request será tratada como todas as outras solicitações em andamento. Devido a problemas de simultaneidade, é possível que, do ponto de vista do HAL, uma chamada process_capture_request() possa ser iniciada após o flush ter sido invocado, mas ainda não ter retornado. Se tal chamada acontecer antes do retorno de flush() , o HAL deverá tratar a nova solicitação de captura como outras solicitações pendentes em andamento (veja o item 4 abaixo).
Mais especificamente, o HAL deve seguir os requisitos abaixo para vários casos:
- Para capturas que são muito atrasadas para o HAL cancelar/parar, e serão concluídas normalmente pelo HAL; ou seja, o HAL pode enviar shutter/notify e process_capture_result e buffers normalmente.
- Para solicitações pendentes que não realizaram nenhum processamento, o HAL deve chamar notify CAMERA3_MSG_ERROR_REQUEST, e retornar todos os buffers de saída com process_capture_result no estado de erro (CAMERA3_BUFFER_STATUS_ERROR). O HAL não deve colocar o limite de liberação em um estado de erro; em vez disso, os limites de liberação devem ser definidos para os limites de aquisição passados pela estrutura, ou -1 se já tiverem sido aguardados pelo HAL. Este também é o caminho a seguir para quaisquer capturas para as quais o HAL já chamou notify() com CAMERA3_MSG_SHUTTER, mas não produzirá metadados/buffers válidos. Após CAMERA3_MSG_ERROR_REQUEST, para um determinado quadro, apenas process_capture_results com buffers em CAMERA3_BUFFER_STATUS_ERROR são permitidos. Nenhuma outra notificação ou process_capture_result com metadados não nulos é permitida.
Para solicitações pendentes parcialmente concluídas que não terão todos os buffers de saída ou talvez faltem metadados, o HAL deverá seguir abaixo:
3.1. Chame a notificação com CAMERA3_MSG_ERROR_RESULT se alguns dos metadados de resultado esperados (ou seja, um ou mais metadados parciais) não estiverem disponíveis para a captura.
3.2. Chame a notificação com CAMERA3_MSG_ERROR_BUFFER para cada buffer que não será produzido para a captura.
3.3 Chame a notificação com CAMERA3_MSG_SHUTTER com o carimbo de data/hora de captura antes que quaisquer buffers/metadados sejam retornados com process_capture_result.
3.4 Para capturas que produzirão algum resultado, o HAL não deve chamar CAMERA3_MSG_ERROR_REQUEST, pois isso indica falha completa.
3.5. Buffers/metadados válidos devem ser passados para a estrutura normalmente.
3.6. Os buffers com falha devem ser retornados à estrutura conforme descrito para o caso 2. Mas os buffers com falha não precisam seguir a ordem estrita que os buffers válidos seguem e podem estar fora de ordem em relação aos buffers válidos. Por exemplo, se os buffers A, B, C, D, E forem enviados, D e E falharem, então A, E, B, D, C é uma ordem de retorno aceitável.
3.7. Para metadados totalmente ausentes, chamar CAMERA3_MSG_ERROR_RESULT é suficiente, não há necessidade de chamar process_capture_result com metadados NULL ou equivalente.
- Se um flush() for invocado enquanto uma invocação de process_capture_request() estiver ativa, essa chamada de processo deverá retornar o mais rápido possível. Além disso, se uma chamada process_capture_request() for feita após flush() ter sido invocada, mas antes de flush() retornar, a solicitação de captura fornecida pela chamada process_capture_request atrasada deve ser tratada como uma solicitação pendente no caso nº 2 acima.
flush() só deve retornar quando não houver mais buffers ou solicitações pendentes no HAL. A estrutura pode chamar configure_streams (já que o estado HAL está agora desativado) ou pode emitir novas solicitações.
Observe que é suficiente oferecer suporte apenas a casos de resultados totalmente bem-sucedidos e com falha total. No entanto, é altamente desejável oferecer suporte também aos casos de falha parcial, pois isso poderia ajudar a melhorar o desempenho geral da chamada de descarga.
Requisitos de desempenho:
O HAL deverá retornar desta chamada em 100ms, e deverá retornar desta chamada em 1000ms. E esta chamada não deve ser bloqueada por mais tempo do que a latência do pipeline (consulte S7 para definição).
Versão informação:
disponível apenas se a versão do dispositivo >= CAMERA_DEVICE_API_VERSION_3_1.
Valores de retorno:
0: Em uma descarga bem-sucedida da câmera HAL.
-EINVAL: Se a entrada estiver malformada (o dispositivo não é válido).
-ENODEV: Se o dispositivo da câmera encontrou um erro grave. Depois que esse erro for retornado, apenas o método close() poderá ser chamado com sucesso pela estrutura.
| void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, vendor_tag_query_ops_t *ops) |
get_metadata_vendor_tag_ops:
Obtenha métodos para consultar informações de tags de metadados de extensão do fornecedor. O HAL deve preencher todos os métodos de operação de tags de fornecedor ou deixar as operações inalteradas se nenhuma tag de fornecedor for definida.
A definição de vendor_tag_query_ops_t pode ser encontrada em system/media/camera/include/system/camera_metadata.h.
>= CAMERA_DEVICE_API_VERSION_3_2: DEPRECADO. Esta função foi obsoleta e deve ser definida como NULL pelo HAL. Implemente get_vendor_tag_ops em camera_common.h .
| int(* inicializar)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
inicializar:
Inicialização única para passar ponteiros de função de retorno de chamada da estrutura para o HAL. Será chamado uma vez após uma chamada open() bem-sucedida, antes de qualquer outra função ser chamada na estrutura camera3_device_ops .
Requisitos de desempenho:
Esta deve ser uma chamada sem bloqueio. O HAL deverá retornar desta chamada em 5ms, e deverá retornar desta chamada em 10ms.
Valores de retorno:
0: Na inicialização bem-sucedida
-ENODEV: Se a inicialização falhar. Somente close() pode ser chamado com sucesso pela estrutura depois disso.
| int(* process_capture_request)(const struct camera3_device *, camera3_capture_request_t *request) |
solicitação_de_captura_de_processo:
Envie uma nova solicitação de captura ao HAL. O HAL não deve retornar desta chamada até que esteja pronto para aceitar a próxima solicitação a ser processada. Apenas uma chamada para process_capture_request() será feita por vez pela estrutura, e as chamadas serão todas do mesmo thread. A próxima chamada para process_capture_request() será feita assim que uma nova solicitação e seus buffers associados estiverem disponíveis. Em um cenário normal de visualização, isso significa que a função será chamada novamente pela estrutura quase que instantaneamente.
O processamento real da solicitação é assíncrono, com os resultados da captura sendo retornados pelo HAL por meio da chamada process_capture_result(). Esta chamada requer que os metadados do resultado estejam disponíveis, mas os buffers de saída podem simplesmente fornecer barreiras de sincronização para aguardar. Espera-se que várias solicitações estejam em andamento ao mesmo tempo, para manter a taxa de quadros de saída total.
A estrutura mantém a propriedade da estrutura de solicitação. Só é garantido que seja válido durante esta chamada. O dispositivo HAL deve fazer cópias das informações que precisa reter para o processamento da captura. O HAL é responsável por aguardar e fechar as cercas dos buffers e retornar os identificadores do buffer para a estrutura.
O HAL deve gravar o descritor de arquivo para o limite de sincronização de liberação do buffer de entrada em input_buffer->release_fence, se input_buffer não for NULL. Se o HAL retornar -1 para o limite de sincronização de liberação do buffer de entrada, a estrutura estará livre para reutilizar imediatamente o buffer de entrada. Caso contrário, a estrutura aguardará a sincronização antes de recarregar e reutilizar o buffer de entrada.
>= CAMERA_DEVICE_API_VERSION_3_2:
Os buffers de entrada/saída fornecidos pela estrutura em cada solicitação podem ser totalmente novos (nunca antes vistos pela HAL).
Considerações de desempenho:
O manuseio de um novo buffer deve ser extremamente leve e não deve haver degradação da taxa de quadros ou introdução de jitter de quadro.
Esta chamada deve retornar rápido o suficiente para garantir que a taxa de quadros solicitada possa ser sustentada, especialmente para casos de streaming (configurações de qualidade de pós-processamento definidas como FAST). O HAL deve retornar esta chamada em intervalo de 1 quadro e deve retornar desta chamada em intervalos de 4 quadros.
Valores de retorno:
0: Em um início bem-sucedido do processamento da solicitação de captura
-EINVAL: Se a entrada estiver malformada (as configurações são NULL quando não permitidas, há 0 buffers de saída, etc.) e o processamento de captura não pode ser iniciado. Falhas durante o processamento da solicitação devem ser tratadas chamando camera3_callback_ops_t.notify() . No caso deste erro, a estrutura manterá a responsabilidade pelas cercas dos buffers de fluxo e pelos identificadores dos buffers; o HAL não deve fechar as cercas ou retornar esses buffers com process_capture_result.
-ENODEV: Se o dispositivo da câmera encontrou um erro grave. Depois que esse erro for retornado, apenas o método close() poderá ser chamado com sucesso pela estrutura.
| int(*register_stream_buffers)(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
registrar_stream_buffers:
>= CAMERA_DEVICE_API_VERSION_3_2:
DESCONTINUADA. Isso não será chamado e deve ser definido como NULL.
<= CAMERA_DEVICE_API_VERSION_3_1:
Registre buffers para um determinado fluxo com o dispositivo HAL. Este método é chamado pela estrutura depois que um novo fluxo é definido por configure_streams e antes que os buffers desse fluxo sejam incluídos em uma solicitação de captura. Se o mesmo fluxo estiver listado em uma chamada configure_streams() subsequente, Register_stream_buffers não será chamado novamente para esse fluxo.
A estrutura não precisa registrar buffers para todos os fluxos configurados antes de enviar a primeira solicitação de captura. Isso permite uma inicialização rápida para visualização (ou casos de uso semelhantes) enquanto outros fluxos ainda estão sendo alocados.
Este método destina-se a permitir que o dispositivo HAL mapeie ou prepare os buffers para uso posterior. Os buffers transmitidos já estarão bloqueados para uso. Ao final da chamada, todos os buffers devem estar prontos para serem retornados ao stream. O argumento buffer_set é válido apenas durante esta chamada.
Se o formato de fluxo foi definido como HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, o HAL da câmera deverá inspecionar os buffers transmitidos aqui para determinar qualquer informação de formato de pixel privado da plataforma.
Requisitos de desempenho:
Esta deve ser uma chamada sem bloqueio. O HAL deverá retornar desta chamada em 1ms, e deverá retornar desta chamada em 5ms.
Valores de retorno:
0: No registro bem-sucedido dos novos buffers de fluxo
-EINVAL: Se stream_buffer_set não se referir a um fluxo ativo válido ou se a matriz de buffers for inválida.
-ENOMEM: Se houve falha no cadastro dos buffers. A estrutura deve considerar todos os buffers de fluxo como não registrados e pode tentar registrar novamente mais tarde.
-ENODEV: Se houver um erro fatal e o dispositivo não estiver mais operacional. Somente close() pode ser chamado com sucesso pela estrutura após esse erro ser retornado.
A documentação desta estrutura foi gerada a partir do seguinte arquivo:
- hardware/libhardware/incluir/hardware/ camera3.h