camera3_device_ops مرجع ساختار

configure_streams:

فقط CAMERA_DEVICE_API_VERSION_3_0:

خط لوله پردازش دستگاه دوربین HAL را بازنشانی کنید و جریان های ورودی و خروجی جدیدی را تنظیم کنید. این فراخوانی هر پیکربندی جریان موجود را با جریان‌های تعریف‌شده در stream_list جایگزین می‌کند. این متد حداقل یک بار پس از مقدار اولیه () فراخوانی می شود، قبل از اینکه درخواستی با ()process_capture_request ارسال شود.

stream_list باید حداقل یک جریان با قابلیت خروجی داشته باشد و ممکن است حاوی بیش از یک جریان با قابلیت ورودی نباشد.

stream_list ممکن است حاوی جریان‌هایی باشد که در مجموعه جریان‌های فعال فعلی نیز هستند (از تماس قبلی با configure_stream()). این جریان‌ها از قبل مقادیر معتبری برای استفاده، max_buffers و نشانگر خصوصی خواهند داشت.

اگر چنین جریانی قبلاً بافرهای خود را ثبت کرده باشد، register_stream_buffers() دوباره برای جریان فراخوانی نمی شود و بافرهای جریان می توانند بلافاصله در درخواست های ورودی گنجانده شوند.

اگر HAL به دلیل پیکربندی جدید نیاز به تغییر پیکربندی جریان برای یک جریان موجود داشته باشد، ممکن است مقادیر استفاده و/یا max_buffers را در طول تماس پیکربندی بازنویسی کند.

فریم ورک چنین تغییری را تشخیص می‌دهد و سپس بافرهای جریان را مجدداً تخصیص می‌دهد و قبل از استفاده از بافرهای آن جریان در درخواست، دوباره register_stream_buffers() را فراخوانی می‌کند.

اگر یک جریان فعلی فعال در stream_list گنجانده نشده باشد، HAL ممکن است با خیال راحت هر گونه ارجاع به آن جریان را حذف کند. در فراخوانی configure() بعدی توسط فریمورک استفاده مجدد نخواهد شد و تمام بافرهای gralloc مربوط به آن پس از بازگشت فراخوان configure_streams() آزاد خواهند شد.

ساختار stream_list متعلق به چارچوب است و ممکن است پس از تکمیل این فراخوانی قابل دسترسی نباشد. آدرس یک ساختار جداگانه camera3_stream_t برای دسترسی توسط HAL تا پایان اولین فراخوانی configure_stream () که دیگر شامل آن camera3_stream_t در آرگومان stream_list نمی شود، معتبر باقی می ماند. HAL ممکن است مقادیری را در ساختار جریان خارج از نشانگر خصوصی تغییر ندهد، به جز اعضای usage و max_buffers در طول فراخوانی configure_streams() خود.

اگر جریان جدید باشد، فیلدهای usage، max_buffer و نشانگر خصوصی ساختار استریم همگی روی 0 تنظیم می‌شوند. دستگاه HAL باید این فیلدها را قبل از بازگشت configure_streams () تنظیم کند. سپس این فیلدها توسط چارچوب و ماژول gralloc پلت فرم برای تخصیص بافرهای gralloc برای هر جریان استفاده می شود.

قبل از اینکه چنین جریان جدیدی بتواند بافرهای خود را در یک درخواست ضبط قرار دهد، فریم ورک با آن جریان ، register_stream_buffers() را فراخوانی می کند. با این حال، چارچوب لازم نیست قبل از ارسال درخواست، بافرها را برای همه جریان‌ها ثبت کند. این امکان راه اندازی سریع (به عنوان مثال) یک جریان پیش نمایش را فراهم می کند، با تخصیص برای جریان های دیگر که بعدا یا همزمان اتفاق می افتد.

فقط CAMERA_DEVICE_API_VERSION_3_1:

خط لوله پردازش دستگاه دوربین HAL را بازنشانی کنید و جریان های ورودی و خروجی جدیدی را تنظیم کنید. این فراخوانی هر پیکربندی جریان موجود را با جریان‌های تعریف‌شده در stream_list جایگزین می‌کند. این متد حداقل یک بار پس از مقدار اولیه () فراخوانی می شود، قبل از اینکه درخواستی با ()process_capture_request ارسال شود.

stream_list باید حداقل یک جریان با قابلیت خروجی داشته باشد و ممکن است حاوی بیش از یک جریان با قابلیت ورودی نباشد.

stream_list ممکن است حاوی جریان‌هایی باشد که در مجموعه جریان‌های فعال فعلی نیز هستند (از تماس قبلی با configure_stream()). این جریان‌ها از قبل مقادیر معتبری برای استفاده، max_buffers و نشانگر خصوصی خواهند داشت.

اگر چنین جریانی قبلاً بافرهای خود را ثبت کرده باشد، register_stream_buffers() دوباره برای جریان فراخوانی نمی شود و بافرهای جریان می توانند بلافاصله در درخواست های ورودی گنجانده شوند.

اگر HAL به دلیل پیکربندی جدید نیاز به تغییر پیکربندی جریان برای یک جریان موجود داشته باشد، ممکن است مقادیر استفاده و/یا max_buffers را در طول تماس پیکربندی بازنویسی کند.

فریم ورک چنین تغییری را تشخیص می‌دهد و سپس بافرهای جریان را مجدداً تخصیص می‌دهد و قبل از استفاده از بافرهای آن جریان در درخواست، دوباره register_stream_buffers() را فراخوانی می‌کند.

اگر یک جریان فعلی فعال در stream_list گنجانده نشده باشد، HAL ممکن است با خیال راحت هر گونه ارجاع به آن جریان را حذف کند. در فراخوانی configure() بعدی توسط فریمورک استفاده مجدد نخواهد شد و تمام بافرهای gralloc مربوط به آن پس از بازگشت فراخوان configure_streams() آزاد خواهند شد.

ساختار stream_list متعلق به چارچوب است و ممکن است پس از تکمیل این فراخوانی قابل دسترسی نباشد. آدرس یک ساختار جداگانه camera3_stream_t برای دسترسی توسط HAL تا پایان اولین فراخوانی configure_stream () که دیگر شامل آن camera3_stream_t در آرگومان stream_list نمی شود، معتبر باقی می ماند. HAL ممکن است مقادیری را در ساختار جریان خارج از نشانگر خصوصی تغییر ندهد، به جز اعضای usage و max_buffers در طول فراخوانی configure_streams() خود.

اگر جریان جدید باشد، فیلدهای max_buffer و نشانگر خصوصی ساختار جریان همه روی 0 تنظیم می‌شوند. میزان استفاده روی پرچم‌های استفاده مصرف‌کننده تنظیم می‌شود. دستگاه HAL باید این فیلدها را قبل از بازگشت ()configure_streams تنظیم کند. سپس این فیلدها توسط چارچوب و ماژول gralloc پلت فرم برای تخصیص بافرهای gralloc برای هر جریان استفاده می شود.

قبل از اینکه چنین جریان جدیدی بتواند بافرهای خود را در یک درخواست ضبط قرار دهد، فریم ورک با آن جریان ، register_stream_buffers() را فراخوانی می کند. با این حال، چارچوب لازم نیست قبل از ارسال درخواست، بافرها را برای همه جریان‌ها ثبت کند. این امکان راه اندازی سریع (به عنوان مثال) یک جریان پیش نمایش را فراهم می کند، با تخصیص برای جریان های دیگر که بعدا یا همزمان اتفاق می افتد.

>= CAMERA_DEVICE_API_VERSION_3_2:

خط لوله پردازش دستگاه دوربین HAL را بازنشانی کنید و جریان های ورودی و خروجی جدیدی را تنظیم کنید. این فراخوانی هر پیکربندی جریان موجود را با جریان‌های تعریف‌شده در stream_list جایگزین می‌کند. این متد حداقل یک بار پس از مقدار اولیه () فراخوانی می شود، قبل از اینکه درخواستی با ()process_capture_request ارسال شود.

stream_list باید حداقل یک جریان با قابلیت خروجی داشته باشد و ممکن است حاوی بیش از یک جریان با قابلیت ورودی نباشد.

stream_list ممکن است حاوی جریان‌هایی باشد که در مجموعه جریان‌های فعال فعلی نیز هستند (از تماس قبلی با configure_stream()). این جریان‌ها از قبل مقادیر معتبری برای استفاده، max_buffers و نشانگر خصوصی خواهند داشت.

اگر HAL به دلیل پیکربندی جدید نیاز به تغییر پیکربندی جریان برای یک جریان موجود داشته باشد، ممکن است مقادیر استفاده و/یا max_buffers را در طول تماس پیکربندی بازنویسی کند.

چارچوب چنین تغییری را تشخیص می‌دهد و ممکن است قبل از استفاده از بافرهای آن جریان در یک درخواست، بافرهای جریان را مجدداً اختصاص دهد.

اگر یک جریان فعلی فعال در stream_list گنجانده نشده باشد، HAL ممکن است با خیال راحت هر گونه ارجاع به آن جریان را حذف کند. در فراخوانی configure() بعدی توسط فریمورک استفاده مجدد نخواهد شد و تمام بافرهای gralloc مربوط به آن پس از بازگشت فراخوان configure_streams() آزاد خواهند شد.

ساختار stream_list متعلق به چارچوب است و ممکن است پس از تکمیل این فراخوانی قابل دسترسی نباشد. آدرس یک ساختار جداگانه camera3_stream_t برای دسترسی توسط HAL تا پایان اولین فراخوانی configure_stream () که دیگر شامل آن camera3_stream_t در آرگومان stream_list نمی شود، معتبر باقی می ماند. HAL ممکن است مقادیری را در ساختار جریان خارج از نشانگر خصوصی تغییر ندهد، به جز اعضای usage و max_buffers در طول فراخوانی configure_streams() خود.

اگر جریان جدید باشد، فیلدهای max_buffer و نشانگر خصوصی ساختار جریان همه روی 0 تنظیم می‌شوند. میزان استفاده روی پرچم‌های استفاده مصرف‌کننده تنظیم می‌شود. دستگاه HAL باید این فیلدها را قبل از بازگشت ()configure_streams تنظیم کند. سپس این فیلدها توسط چارچوب و ماژول gralloc پلت فرم برای تخصیص بافرهای gralloc برای هر جریان استفاده می شود.

بافرهای تازه تخصیص داده شده ممکن است در هر زمان توسط چارچوب در یک درخواست ضبط گنجانده شوند. هنگامی که یک بافر gralloc با process_capture_result به فریم ورک برگردانده می شود (و release_fence مربوطه آن علامت داده شده است)، فریم ورک ممکن است در هر زمانی آن را آزاد کند یا دوباره از آن استفاده کند.

پیش شرط ها:

فریم ورک فقط زمانی این متد را فراخوانی می کند که هیچ تصویری در حال پردازش نباشد. یعنی تمام نتایج به فریمورک برگردانده شده اند و تمام بافرهای ورودی و خروجی در حین پرواز برگردانده شده اند و حصارهای همگام سازی آزادسازی آنها توسط HAL سیگنال داده شده است. در حالی که فراخوانی configure_streams() در حال انجام است، فریم ورک درخواست‌های جدیدی برای ضبط ارسال نمی‌کند.

شرایط پسا:

دستگاه HAL باید خود را طوری پیکربندی کند که حداکثر نرخ فریم خروجی ممکن را با توجه به اندازه‌ها و قالب‌های جریان‌های خروجی، همانطور که در فراداده استاتیک دستگاه دوربین مستند شده است، ارائه دهد.

ملزومات اجرا:

انتظار می رود این تماس سنگین وزن باشد و احتمالاً چند صد میلی ثانیه طول می کشد تا تکمیل شود، زیرا ممکن است نیاز به تنظیم مجدد و پیکربندی مجدد سنسور تصویر و خط لوله پردازش دوربین داشته باشد. با این وجود، دستگاه HAL باید تلاش کند تا تأخیر پیکربندی مجدد را به حداقل برساند تا مکث‌های قابل مشاهده توسط کاربر در طول تغییرات حالت عملیاتی برنامه (مانند تغییر از ضبط ثابت به ضبط ویدیو) به حداقل برسد.

HAL باید از این تماس در 500 میلی ثانیه برگردد و باید از این تماس در 1000 میلی ثانیه برگردد.

مقادیر برگشتی:

0: در پیکربندی پخش جریانی موفق

-EINVAL: اگر پیکربندی جریان درخواستی نامعتبر باشد. چند نمونه از پیکربندی‌های جریان نامعتبر عبارتند از:

• شامل بیش از 1 جریان با قابلیت ورودی (INPUT یا BIDIRECTIONAL)
• بدون هیچ جریانی با قابلیت خروجی (OUTPUT یا BIDIRECTIONAL)
• از جمله جریان‌هایی با قالب‌های پشتیبانی‌نشده، یا اندازه پشتیبانی‌نشده برای آن قالب.
• از جمله تعداد زیادی جریان خروجی با یک قالب خاص.
• پیکربندی چرخش پشتیبانی نشده (فقط برای دستگاه‌های دارای نسخه >= CAMERA_DEVICE_API_VERSION_3_3 اعمال می‌شود)
• اندازه‌ها/ قالب‌های جریان، الزامات camera3_stream_configuration_t->operation_mode را برای حالت غیر NORMAL برآورده نمی‌کنند، یا عملیات_حالت درخواستی توسط HAL پشتیبانی نمی‌شود. (فقط برای دستگاه هایی با نسخه >= CAMERA_DEVICE_API_VERSION_3_3 اعمال می شود)

توجه داشته باشید که چارچوبی که یک پیکربندی جریان نامعتبر را ارسال می‌کند، عملکرد عادی نیست، زیرا تنظیمات جریان قبل از پیکربندی بررسی می‌شوند. پیکربندی نامعتبر به این معنی است که یک اشکال در کد چارچوب وجود دارد، یا عدم تطابق بین ابرداده استاتیک HAL و الزامات موجود در جریان‌ها وجود دارد.

-ENODEV: اگر خطای مهلکی رخ داده باشد و دستگاه دیگر کار نکند. پس از بازگشت این خطا، فقط ()close می تواند با موفقیت توسط فریمورک فراخوانی شود.

تعریف در خط 2769 فایل camera3.h .

construct_default_request_settings:

تنظیمات عکسبرداری را برای موارد استفاده از دوربین استاندارد ایجاد کنید.

دستگاه باید یک بافر تنظیمات را برگرداند که برای مطابقت با مورد درخواستی پیکربندی شده است، که باید یکی از فهرست‌های CAMERA3_TEMPLATE_* باشد. تمام فیلدهای کنترل درخواست باید گنجانده شود.

HAL مالکیت این ساختار را حفظ می کند، اما اشاره گر به ساختار باید تا زمانی که دستگاه بسته نشود معتبر باشد. چارچوب و HAL ممکن است پس از بازگشت بافر توسط این فراخوانی، بافر را تغییر ندهند. همان بافر ممکن است برای فراخوانی های بعدی برای همان الگو یا سایر الگوها برگردانده شود.

ملزومات اجرا:

این باید یک تماس غیر مسدود باشد. HAL باید از این تماس در 1 میلی ثانیه برگردد و باید از این تماس در 5 میلی ثانیه برگردد.

مقادیر برگشتی:

فراداده معتبر: در ایجاد موفقیت آمیز بافر تنظیمات پیش فرض.

NULL: در صورت بروز خطای مهلک. پس از برگرداندن این، فقط متد ()close می تواند با موفقیت توسط فریمورک فراخوانی شود.

تعریف در خط 2859 فایل camera3.h .

زباله:

حالت اشکال زدایی دستگاه دوربین را چاپ کنید. هنگامی که از سرویس دوربین برای یک اشکال‌زدایی dump درخواست می‌شود، این فریم‌ورک فراخوانی می‌شود، که در هنگام استفاده از ابزار dumpsys یا هنگام گرفتن گزارش اشکال رخ می‌دهد.

توصیفگر فایل منتقل شده می تواند برای نوشتن متن اشکال زدایی با استفاده از dprintf() یا write() استفاده شود. متن باید فقط در رمزگذاری ASCII باشد.

ملزومات اجرا:

این باید یک تماس غیر مسدود باشد. HAL باید از این تماس در 1 میلی ثانیه برگردد، باید از این تماس در 10 میلی ثانیه برگردد. این تماس باید از بن بست جلوگیری کند، زیرا ممکن است در هر نقطه از عملکرد دوربین تماس گرفته شود. هر نوع همگام سازی اولیه مورد استفاده (مانند قفل های mutex یا سمافورها) باید با یک بازه زمانی به دست آید.

تعریف در خط 2971 فایل camera3.h .

فلاش:

تمام عکس‌های در حال پردازش و تمام بافرهای موجود در خط لوله را در دستگاه داده شده شستشو دهید. فریم ورک از این برای حذف همه حالت ها در سریع ترین زمان ممکن استفاده می کند تا برای یک فراخوانی configure_streams() آماده شود.

برای بازگشت موفقیت آمیز به هیچ بافری نیاز نیست، بنابراین هر بافری که در زمان flush() نگهداری می شود (خواه با موفقیت پر شده باشد یا نه) ممکن است با CAMERA3_BUFFER_STATUS_ERROR برگردانده شود. توجه داشته باشید که HAL همچنان مجاز است در طول این تماس بافرهای معتبر (CAMERA3_BUFFER_STATUS_OK) را برگرداند، مشروط بر اینکه با موفقیت پر شوند.

انتظار می رود تمام درخواست های موجود در HAL در اسرع وقت بازگردانده شوند. درخواست‌های در حال پردازش باید فوراً خطاها را برگردانند. هر بلوک سخت افزاری قابل وقفه باید متوقف شود، و هر بلوک بدون وقفه باید منتظر ماند.

flush() ممکن است همزمان با process_capture_request() فراخوانی شود، با این انتظار که process_capture_request به سرعت بازگردد و درخواست ارسال شده در آن فراخوان process_capture_request مانند سایر درخواست های حین پرواز رفتار شود. به دلیل مشکلات همزمانی، ممکن است از دیدگاه HAL، یک فراخوانی ()process_capture_request ممکن است پس از فراخوانی flush آغاز شود اما هنوز برنگشته است. اگر چنین تماسی قبل از بازگشت flush() اتفاق بیفتد، HAL باید درخواست ضبط جدید را مانند سایر درخواست‌های معلق در حین پرواز رفتار کند (به شماره 4 زیر مراجعه کنید).

به طور خاص، HAL باید الزامات زیر را برای موارد مختلف دنبال کند:

1. برای عکسبرداری هایی که برای لغو/توقف HAL ​​خیلی دیر است و به طور معمول توسط HAL تکمیل می شود. به عنوان مثال HAL می تواند شاتر/اعلان و process_capture_result و بافرها را به طور معمول ارسال کند.
2. برای درخواست‌های معلق که هیچ پردازشی انجام نداده‌اند، HAL باید با notify CAMERA3_MSG_ERROR_REQUEST تماس بگیرد و تمام بافرهای خروجی را با process_capture_result در حالت خطا (CAMERA3_BUFFER_STATUS_ERROR) برگرداند. HAL نباید حصار رهاسازی را در حالت خطا قرار دهد، در عوض، حصارهای آزادسازی باید روی حصارهای کسب شده توسط چارچوب یا -1 تنظیم شوند، اگر قبلاً توسط HAL منتظر مانده اند. همچنین این مسیری است که باید برای هر عکس برداری که HAL قبلاً برای آن notify() با CAMERA3_MSG_SHUTTER فراخوانی کرده است، دنبال کنید، اما هیچ متادیتا/بافر معتبری برای آن تولید نمی کند. پس از CAMERA3_MSG_ERROR_REQUEST، برای یک فریم معین، فقط process_capture_results با بافر در CAMERA3_BUFFER_STATUS_ERROR مجاز است. هیچ اطلاعیه یا process_capture_result بیشتر با فراداده غیر تهی مجاز نیست.

3. برای درخواست‌های معلق نیمه تکمیل‌شده که تمام بافرهای خروجی را ندارند یا احتمالاً ابرداده‌های موجود ندارند، HAL باید به شرح زیر باشد:

   3.1. اگر برخی از فراداده‌های نتیجه مورد انتظار (یعنی یک یا چند فراداده جزئی) برای ضبط در دسترس نیستند، با CAMERA3_MSG_ERROR_RESULT تماس بگیرید.

   3.2. با CAMERA3_MSG_ERROR_BUFFER برای هر بافری که برای ضبط تولید نمی شود، تماس بگیرید.

   3.3 با CAMERA3_MSG_SHUTTER با مهر زمانی ضبط تماس بگیرید قبل از اینکه هر بافر/فراداده با process_capture_result برگردانده شود.

   3.4 برای عکس برداری هایی که برخی نتایج را به همراه خواهد داشت، HAL نباید CAMERA3_MSG_ERROR_REQUEST را فراخوانی کند، زیرا این نشان دهنده شکست کامل است.

   3.5. بافر/فراداده معتبر باید به طور معمول به چارچوب ارسال شود.

   3.6. بافرهای ناموفق باید همانطور که در مورد 2 توضیح داده شد به چارچوب برگردانده شوند. اما بافرهای ناموفق مجبور نیستند از ترتیب دقیق بافرهای معتبر پیروی کنند و ممکن است نسبت به بافرهای معتبر خارج از نظم باشند. به عنوان مثال، اگر بافرهای A، B، C، D، E ارسال شوند، D و E ناموفق باشند، A، E، B، D، C یک سفارش بازگشت قابل قبول است.

   3.7. برای فراداده کاملاً از دست رفته، فراخوانی CAMERA3_MSG_ERROR_RESULT کافی است، نیازی به فراخوانی process_capture_result با متادیتا NULL یا معادل آن نیست.

4. اگر یک flush () فراخوانی شود در حالی که یک فراخوانی process_capture_request () فعال است، آن فراخوانی فرآیند باید در اسرع وقت بازگردد. علاوه بر این، اگر فراخوانی ()process_capture_request بعد از فراخوانی flush() انجام شود، اما قبل از بازگشت flush() ، درخواست ضبط ارائه شده توسط فراخوانی late process_capture_request باید مانند یک درخواست در حال انتظار در مورد شماره 2 بالا تلقی شود.

flush() تنها زمانی باید برگردد که هیچ بافر یا درخواست دیگری در HAL باقی نماند. فریم ورک ممکن است configure_streams را فراخوانی کند (زیرا حالت HAL اکنون متوقف شده است) یا ممکن است درخواست های جدیدی صادر کند.

توجه داشته باشید که فقط پشتیبانی از موارد نتایج کاملاً موفق و کاملاً ناموفق کافی است. با این حال، پشتیبانی از موارد شکست جزئی نیز بسیار مطلوب است، زیرا می تواند به بهبود عملکرد کلی تماس فلاش کمک کند.

ملزومات اجرا:

HAL باید از این تماس در 100ms برگردد و باید از این تماس در 1000ms برگردد. و این تماس نباید بیشتر از تاخیر خط لوله مسدود شود (برای تعریف به S7 مراجعه کنید).

اطلاعات نسخه:

فقط در صورت نسخه دستگاه >= CAMERA_DEVICE_API_VERSION_3_1 در دسترس است.

مقادیر برگشتی:

0: در یک فلاش موفقیت آمیز دوربین HAL.

-EINVAL: اگر ورودی بد شکل باشد (دستگاه معتبر نیست).

-ENODEV: اگر دستگاه دوربین با خطای جدی مواجه شده باشد. پس از بازگشت این خطا، تنها متد ()close می تواند با موفقیت توسط فریمورک فراخوانی شود.

تعریف در خط 3077 فایل camera3.h .

get_metadata_vendor_tag_ops:

روش هایی برای پرس و جو برای اطلاعات برچسب فراداده پسوند فروشنده دریافت کنید. HAL باید تمام روش‌های عملیات تگ فروشنده را پر کند یا اگر تگ فروشنده تعریف نشده باشد، عملیات را بدون تغییر باقی بگذارد.

تعریف vendor_tag_query_ops_t را می توان در system/media/camera/include/system/camera_metadata.h یافت.

>= CAMERA_DEVICE_API_VERSION_3_2: منسوخ شده است. این تابع منسوخ شده است و باید توسط HAL روی NULL تنظیم شود. لطفاً به جای آن get_vendor_tag_ops را در camera_common.h پیاده سازی کنید.

تعریف در خط 2950 فایل camera3.h .

مقداردهی اولیه:

مقداردهی اولیه برای ارسال نشانگرهای تابع فراخوانی چارچوب به HAL. یک بار پس از یک فراخوانی open() موفق فراخوانی می شود، قبل از اینکه هر تابع دیگری در ساختار camera3_device_ops فراخوانی شود.

ملزومات اجرا:

این باید یک تماس غیر مسدود باشد. HAL باید از این تماس در 5 میلی ثانیه برگردد و باید از این تماس در 10 میلی ثانیه برگردد.

مقادیر برگشتی:

0: در مقداردهی اولیه موفقیت آمیز

-ENODEV: اگر مقداردهی اولیه ناموفق باشد. فقط کل () را می توان با موفقیت توسط فریمورک پس از این فراخوانی کرد.

تعریف در خط 2530 فایل camera3.h .

process_capture_request:

یک درخواست ضبط جدید به HAL ارسال کنید. HAL تا زمانی که آماده پذیرش درخواست بعدی برای پردازش نباشد، نباید از این تماس بازگردد. فقط یک فراخوانی به process_capture_request() در یک زمان توسط فریمورک انجام می شود و همه فراخوانی ها از یک رشته خواهند بود. فراخوان بعدی به process_capture_request() به محض در دسترس بودن یک درخواست جدید و بافرهای مرتبط با آن انجام می شود. در یک سناریوی پیش‌نمایش عادی، این بدان معناست که تابع تقریباً بلافاصله دوباره توسط فریمورک فراخوانی می‌شود.

پردازش درخواست واقعی ناهمزمان است و نتایج ضبط توسط HAL از طریق فراخوانی ()process_capture_result برگردانده می شود. این فراخوانی مستلزم در دسترس بودن فراداده نتیجه است، اما بافرهای خروجی ممکن است به سادگی حصارهای همگام سازی را برای منتظر ماندن فراهم کنند. برای حفظ نرخ فریم خروجی کامل، انتظار می رود چندین درخواست به طور همزمان در حال پرواز باشند.

چارچوب مالکیت ساختار درخواست را حفظ می کند. اعتبار آن فقط در طول این تماس تضمین شده است. دستگاه HAL باید از اطلاعاتی که برای پردازش ضبط نیاز دارد کپی کند. HAL مسئول انتظار و بستن حصارهای بافر و بازگرداندن دسته های بافر به چارچوب است.

اگر input_buffer NULL نباشد، HAL باید توصیفگر فایل را برای حصار همگام‌سازی آزاد بافر ورودی در input_buffer->release_fence بنویسد. اگر HAL -1 را برای حصار همگام سازی انتشار بافر ورودی برگرداند، چارچوب آزاد است تا فوراً از بافر ورودی دوباره استفاده کند. در غیر این صورت، چارچوب قبل از پر کردن و استفاده مجدد از بافر ورودی، روی حصار همگام‌سازی منتظر می‌ماند.

>= CAMERA_DEVICE_API_VERSION_3_2:

بافرهای ورودی/خروجی ارائه شده توسط فریم ورک در هر درخواست ممکن است کاملاً جدید باشند (تا کنون هرگز توسط HAL دیده نشده است).

ملاحظات عملکرد:

مدیریت یک بافر جدید باید بسیار سبک باشد و نباید کاهش نرخ فریم یا لرزش فریم ایجاد شود.

این تماس باید به اندازه کافی سریع برگردد تا اطمینان حاصل شود که نرخ فریم درخواستی می تواند حفظ شود، به خصوص برای موارد پخش (تنظیمات کیفیت پس از پردازش روی FAST تنظیم شده است). HAL باید این تماس را در 1 بازه فریم برگرداند و باید از این تماس در 4 بازه فریم برگردد.

مقادیر برگشتی:

0: در شروع موفقیت آمیز پردازش درخواست ضبط

-EINVAL: اگر ورودی بدشکل باشد (تنظیمات وقتی مجاز نیستند NULL هستند، 0 بافر خروجی وجود دارد و غیره) و پردازش ضبط نمی تواند شروع شود. خطاها در طول پردازش درخواست باید با فراخوانی camera3_callback_ops_t.notify() رسیدگی شود. در صورت بروز این خطا، چارچوب مسئولیت حصارهای بافر جریان و دستگیره های بافر را حفظ خواهد کرد. HAL نباید حصارها را ببندد یا این بافرها را با process_capture_result برگرداند.

-ENODEV: اگر دستگاه دوربین با خطای جدی مواجه شده باشد. پس از بازگشت این خطا، تنها متد ()close می تواند با موفقیت توسط فریمورک فراخوانی شود.

تعریف در خط 2928 فایل camera3.h .

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

منسوخ. این فراخوانی نخواهد شد و باید روی NULL تنظیم شود.

<= CAMERA_DEVICE_API_VERSION_3_1:

بافرها را برای یک جریان معین با دستگاه HAL ثبت کنید. این متد پس از تعریف یک جریان جدید توسط configure_streams و قبل از اینکه بافرهایی از آن جریان در یک درخواست ضبط گنجانده شود توسط فریمورک فراخوانی می شود. اگر همان جریان در یک فراخوانی بعدی configure_streams () فهرست شود، register_stream_buffers دوباره برای آن جریان فراخوانی نخواهد شد.

این چارچوب نیازی به ثبت بافر برای همه جریان‌های پیکربندی‌شده قبل از ارسال اولین درخواست ضبط ندارد. این اجازه می دهد تا راه اندازی سریع برای پیش نمایش (یا موارد استفاده مشابه) در حالی که جریان های دیگر هنوز در حال تخصیص هستند.

این روش در نظر گرفته شده است تا به دستگاه HAL اجازه دهد تا بافرها را برای استفاده بعدی آماده کند. بافرهای ارسال شده در حال حاضر برای استفاده قفل خواهند شد. در پایان تماس، تمام بافرها باید آماده باشند تا به جریان بازگردانده شوند. آرگومان buffer_set فقط برای مدت زمان این فراخوانی معتبر است.

اگر قالب پخش جریانی روی HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED تنظیم شده بود، دوربین HAL باید بافرهای منتقل شده را در اینجا بررسی کند تا اطلاعات قالب پیکسل خصوصی پلتفرم را مشخص کند.

ملزومات اجرا:

این باید یک تماس غیر مسدود باشد. HAL باید از این تماس در 1 میلی ثانیه برگردد و باید از این تماس در 5 میلی ثانیه برگردد.

مقادیر برگشتی:

0: در ثبت موفقیت آمیز بافرهای جریان جدید

-EINVAL: اگر stream_buffer_set به یک جریان فعال معتبر اشاره نداشته باشد، یا اگر آرایه بافر نامعتبر باشد.

-ENOMEM: اگر در ثبت بافرها مشکلی وجود داشت. چارچوب باید تمام بافرهای جریان را ثبت نشده در نظر بگیرد و می‌تواند بعداً دوباره ثبت نام کند.

-ENODEV: اگر یک خطای کشنده وجود داشته باشد و دستگاه دیگر کار کند. پس از بازگشت این خطا، فقط ()close می تواند با موفقیت توسط فریمورک فراخوانی شود.

تعریف در خط 2823 فایل camera3.h .

تعریف در خط 3080 فایل camera3.h .