עזרה בנושא המבנה camera3_device_ops

שדות נתונים
עזרה בנושא המבנה camera3_device_ops

#include < camera3.h >

שדות נתונים

int(*  initialize )(const struct camera3_device *, const camera3_callback_ops_t *callback_ops)
 
int(*  configure_streams )(const struct camera3_device *, camera3_stream_configuration_t *stream_list)
 
int(*  register_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 *, int type)
 
int(*  process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request)
 
void(*  get_metadata_vendor_tag_ops )(const struct camera3_device *, vendor_tag_query_ops_t *ops)
 
void(*  dump )(const struct camera3_device *, int fd)
 
int(*  flush )(const struct camera3_device *)
 
void *  שמורות [8]
 

תיאור מפורט

ההגדרה מופיעה בשורה 2509 בקובץ camera3.h .

מסמכי תיעוד של שדה

int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list)

configure_streams:

CAMERA_DEVICE_API_VERSION_3_0 בלבד:

איך מאפסים את צינור עיבוד הנתונים של מכשיר המצלמה ב-HAL ומגדירים מקורות קלט ופלט חדשים. הקריאה הזו מחליפה את הגדרות הסטרימינג הקיימות בסטרימינגים שהוגדרו ב-stream_list. המטהד הזה ייקרא לפחות פעם אחת אחרי initialize()‎ , לפני שליחת בקשה באמצעות process_capture_request()‎ .

הרשימה stream_list חייבת להכיל לפחות שידור אחד עם יכולת פלט, ואי אפשר לכלול בה יותר משידור אחד עם יכולת קלט.

הרשימה stream_list עשויה להכיל גם מקורות נתונים שנמצאים גם בקבוצת מקורות הנתונים הפעילים הנוכחית (מהקריאה הקודמת ל-configure_stream()). למקורות הנתונים האלה כבר יהיו ערכים תקפים ל-usage, ל-max_buffers ולמצביע הפרטי.

אם מאגרים כאלה כבר רשומים, לא תתבצע קריאה חוזרת ל- register_stream_buffers()‎ עבור המאגר, וניתן יהיה לכלול מאגרים מהמאגר בבקשות הקלט באופן מיידי.

אם ה-HAL צריך לשנות את הגדרת הסטרימינג של סטרימינג קיים בגלל ההגדרה החדשה, הוא עשוי לכתוב מחדש את הערכים של usage ו/או 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 ו-private pointer במבנה של השידור יוגדרו ל-0. מכשיר ה-HAL צריך להגדיר את השדות האלה לפני שהקריאה configure_streams()‎ חוזרת. לאחר מכן, המסגרת ומודול gralloc של הפלטפורמה משתמשים בשדות האלה כדי להקצות את מאגרי ה-gralloc לכל שידור.

כדי שאפשר יהיה לכלול את מאגרי הנתונים של מקור חדש כזה בבקשת הקלטה, המסגרת תבצע קריאה ל- register_stream_buffers()‎ עם המקור הזה. עם זאת, לא חובה לרשום מאגרים ל כל הסטרימינג לפני שליחת הבקשה. כך אפשר להפעיל במהירות (לדוגמה) שידור מקדים, והקצאה של שידורים אחרים תתבצע מאוחר יותר או בו-זמנית.

CAMERA_DEVICE_API_VERSION_3_1 בלבד:

איך מאפסים את צינור עיבוד הנתונים של מכשיר המצלמה ב-HAL ומגדירים מקורות קלט ופלט חדשים. הקריאה הזו מחליפה את הגדרות הסטרימינג הקיימות בסטרימינגים שהוגדרו ב-stream_list. המטהד הזה ייקרא לפחות פעם אחת אחרי initialize()‎ , לפני שליחת בקשה באמצעות process_capture_request()‎ .

הרשימה stream_list חייבת להכיל לפחות שידור אחד עם יכולת פלט, ואי אפשר לכלול בה יותר משידור אחד עם יכולת קלט.

הרשימה stream_list עשויה להכיל גם מקורות נתונים שנמצאים גם בקבוצת מקורות הנתונים הפעילים הנוכחית (מהקריאה הקודמת ל-configure_stream()). למקורות הנתונים האלה כבר יהיו ערכים תקפים ל-usage, ל-max_buffers ולמצביע הפרטי.

אם מאגרים כאלה כבר רשומים, לא תתבצע קריאה חוזרת ל- register_stream_buffers()‎ עבור המאגר, וניתן יהיה לכלול מאגרים מהמאגר בבקשות הקלט באופן מיידי.

אם ה-HAL צריך לשנות את הגדרת הסטרימינג של סטרימינג קיים בגלל ההגדרה החדשה, הוא עשוי לכתוב מחדש את הערכים של usage ו/או 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 ו-private pointer במבנה השידור יוגדרו ל-0. השימוש יוגדר לפי דגלים של שימוש של צרכן. מכשיר ה-HAL צריך להגדיר את השדות האלה לפני שהקריאה configure_streams()‎ חוזרת. לאחר מכן, המסגרת ומודול gralloc של הפלטפורמה משתמשים בשדות האלה כדי להקצות את מאגרי ה-gralloc לכל שידור.

כדי שאפשר יהיה לכלול את מאגרי הנתונים של מקור חדש כזה בבקשת הקלטה, המסגרת תבצע קריאה ל- register_stream_buffers()‎ עם המקור הזה. עם זאת, לא חובה לרשום מאגרים ל כל הסטרימינג לפני שליחת הבקשה. כך אפשר להפעיל במהירות (לדוגמה) שידור מקדים, והקצאה של שידורים אחרים תתבצע מאוחר יותר או בו-זמנית.

>= CAMERA_DEVICE_API_VERSION_3_2:

איך מאפסים את צינור עיבוד הנתונים של מכשיר המצלמה ב-HAL ומגדירים מקורות קלט ופלט חדשים. הקריאה הזו מחליפה את הגדרות הסטרימינג הקיימות בסטרימינגים שהוגדרו ב-stream_list. המטהד הזה ייקרא לפחות פעם אחת אחרי initialize()‎ , לפני שליחת בקשה באמצעות process_capture_request()‎ .

הרשימה stream_list חייבת להכיל לפחות שידור אחד עם יכולת פלט, ואי אפשר לכלול בה יותר משידור אחד עם יכולת קלט.

הרשימה stream_list עשויה להכיל גם מקורות נתונים שנמצאים גם בקבוצת מקורות הנתונים הפעילים הנוכחית (מהקריאה הקודמת ל-configure_stream()). למקורות הנתונים האלה כבר יהיו ערכים תקפים ל-usage, ל-max_buffers ולמצביע הפרטי.

אם ה-HAL צריך לשנות את הגדרת הסטרימינג של סטרימינג קיים בגלל ההגדרה החדשה, הוא עשוי לכתוב מחדש את הערכים של usage ו/או 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 ו-private pointer במבנה השידור יוגדרו ל-0. השימוש יוגדר לפי דגלים של שימוש של צרכן. מכשיר ה-HAL צריך להגדיר את השדות האלה לפני שהקריאה configure_streams()‎ חוזרת. לאחר מכן, המסגרת ומודול gralloc של הפלטפורמה משתמשים בשדות האלה כדי להקצות את מאגרי ה-gralloc לכל שידור.

המערכת עשויה לכלול במסגרת בקשת הקלטה מאגרים חדשים שהוקצו בכל שלב. אחרי שמאגר gralloc מוחזר למסגרת באמצעות process_capture_result (והאות release_fence התואם נשלח), המסגרת עשויה לפנות אותו או להשתמש בו שוב בכל שלב.

תנאים מקדימים:

המערכת תקרא לשיטה הזו רק כשלא מתבצעת עיבוד של צילומים. כלומר, כל התוצאות הוחזרו למסגרת, כל מאגרי הקלט והפלט שנמצאים בטיפול הוחזרו וה-HAL שלח אות לסגירת המחסומים שלהם לסנכרון השחרור. המסגרת לא תשלוח בקשות חדשות לצילום בזמן ההפעלה של הקריאה configure_streams()‎ .

תנאים מתקיימים לאחר ביצוע הפעולה:

מכשיר ה-HAL צריך להגדיר את עצמו כך שיספק את קצב הפריימים המקסימלי האפשרי בפלט, בהתאם לגדלים ולפורמטים של מקורות הפלט, כפי שמתואר במטא-נתונים הסטטיים של מכשיר המצלמה.

דרישות הביצועים:

הקריאה הזו צפויה להיות כבדה, ויכול להיות שיחלפו כמה מאות אלפיות השנייה עד שהיא תושלם, כי יכול להיות שיהיה צורך לאפס ולהגדיר מחדש את חיישן התמונה ואת צינור עיבוד הנתונים של המצלמה. עם זאת, מכשיר ה-HAL צריך לנסות לצמצם את עיכוב ההגדרה מחדש כדי לצמצם את ההשהיות שגלויות למשתמש במהלך שינויים במצב התפעול של האפליקציה (למשל, מעבר מצילומי סטילס לצילומי וידאו).

ה-HAL אמור לחזור מהקריאה הזו תוך 500 אלפיות השנייה, והוא חייב לחזור מהקריאה הזו תוך 1,000 אלפיות השנייה.

ערכים שמוחזרים:

0: כשההגדרה של הסטרימינג הושלמה בהצלחה

-EINVAL: אם הגדרת הסטרימינג המבוקשת לא חוקית. דוגמאות להגדרות לא חוקיות של סטרימינג:

  • הוספת יותר מזרם אחד עם יכולת קלט (INPUT או BIDIRECTIONAL)
  • לא כולל מקורות נתונים עם יכולת פלט (OUTPUT או BIDIRECTIONAL)
  • כולל שידורים בפורמטים שלא נתמכים או בגודל שלא נתמך בפורמט הזה.
  • הוספה של יותר מדי מקורות פלט בפורמט מסוים.
  • הגדרת סבב שלא נתמכת (רלוונטית רק למכשירים בגרסה 3.3 ואילך של CAMERA_DEVICE_API)
  • הפורמטים או הגדלים של הסטרימינג לא עומדים בדרישות של camera3_stream_configuration_t->operation_mode למצבים שאינם NORMAL, או שה-HAL לא תומך ב-operation_mode המבוקש. (הקוד הזה רלוונטי רק למכשירים עם גרסה 3.3 ואילך של CAMERA_DEVICE_API)

חשוב לזכור שהמערכת ששולחת הגדרת סטרימינג לא חוקית היא לא פעילות רגילה, כי הגדרות הסטרימינג נבדקות לפני ההגדרה. הגדרה לא חוקית פירושה שיש באג בקוד של המסגרת, או שיש חוסר התאמה בין המטא-נתונים הסטטיים של HAL לבין הדרישות לגבי הסטרימינג.

-ENODEV: אם הייתה שגיאה קטלנית והמכשיר לא פועל יותר. רק אחרי שהשגיאה הזו מוחזרת, ה-framework יכול לקרוא ל-close() בהצלחה.

ההגדרה מופיעה בשורה 2769 בקובץ camera3.h .

const camera_metadata_t *(* construct_default_request_settings)(const struct camera3_device *, int type)

construct_default_request_settings:‏

ליצור הגדרות צילום לתרחישי שימוש רגילים במצלמה.

המכשיר צריך להחזיר מאגר הגדרות שמוגדר בהתאם לתרחיש לדוגמה המבוקש, שצריך להיות אחד מהמאפיינים של CAMERA3_TEMPLATE_* ‎. צריך לכלול את כל שדות בקרת הבקשה.

ה-HAL שומר על הבעלות על המבנה הזה, אבל ההפניה למבנה חייבת להיות תקפה עד שהמכשיר נסגר. לא ניתן לשנות את המאגר אחרי שהוא מוחזר על ידי הקריאה הזו. יכול להיות שאותו מאגר ייוחזר בקריאות הבאות לאותה תבנית או לתבניות אחרות.

דרישות הביצועים:

זו צריכה להיות קריאה לא חוסמת. ה-HAL אמור לחזור מהקריאה הזו תוך 1ms, וצריך לחזור מהקריאה הזו תוך 5ms.

ערכים שמוחזרים:

מטא-נתונים תקינים: לאחר יצירת מאגר של הגדרות ברירת מחדל בהצלחה.

NULL: במקרה של שגיאה קריטית. לאחר החזרת הערך הזה, המערכת יכולה להפעיל רק את השיטה close().

ההגדרה מופיעה בשורה 2859 בקובץ camera3.h .

void(* dump)(const struct camera3_device *, int fd)

dump:

מדפיסים את מצב ניפוי הבאגים של מכשיר המצלמה. ה-framework יפעיל את הפונקציה הזו כששירות המצלמה יתבקש ליצור דמפ לניפוי באגים. הדבר קורה כשמשתמשים בכלי dumpsys או כשמצלמים דוח באגים.

אפשר להשתמש בתיאור הקובץ שהוענק כדי לכתוב טקסט לניפוי באגים באמצעות dprintf()‎ או write(). ‎ הטקסט צריך להיות בקידוד ASCII בלבד.

דרישות הביצועים:

זו חייבת להיות קריאה לא חוסמת. ה-HAL אמור לחזור מהקריאה הזו תוך 1ms, והוא חייב לחזור מהקריאה הזו תוך 10ms. הקריאה הזו צריכה להימנע מנעילה גורפת (deadlock), כי היא עשויה להתבצע בכל שלב במהלך הפעולה של המצלמה. כל רכיבי הסנכרון הבסיסיים שבהם נעשה שימוש (כמו מנעולים מסוג mutex או סמפורים) צריכים להיות מופעלים עם זמן קצוב לתפוגה.

ההגדרה נמצאת בשורה 2971 בקובץ camera3.h .

int(* flush)(const struct camera3_device *)

flush:‎

שטיפה של כל התמונות והסרטונים שנמצאים כרגע בתהליך עיבוד, ושל כל המאגרים בצינור עיבוד הנתונים במכשיר הנתון. המסגרת תשתמש בכך כדי למחוק את כל המצבים במהירות האפשרית כדי להתכונן לקריאה של configure_streams()‎ .

אין צורך להחזיר מאגרים בהצלחה, כך שכל מאגר שנשמר בזמן flush() (בין אם הוא התמלא בהצלחה ובין אם לא) עשוי להוחזר עם קוד השגיאה CAMERA3_BUFFER_STATUS_ERROR. שימו לב ש-HAL עדיין רשאי להחזיר מאגרים תקינים (CAMERA3_BUFFER_STATUS_OK) במהלך הקריאה הזו, בתנאי שהם מולאו בהצלחה.

כל הבקשות שנמצאות כרגע ב-HAL צפויות לקבל מענה בהקדם האפשרי. בקשות שלא נמצאות בתהליך עיבוד צריכות להחזיר שגיאות באופן מיידי. צריך לעצור כל חסימה של חומרה שניתנת להפרעה, ולהמתין לחסימות שלא ניתן להפריע להן.

אפשר להפעיל את flush() במקביל ל process_capture_request() , מתוך הנחה שהקריאה ל-process_capture_request תחזיר תשובה במהירות והבקשה שנשלחה בקריאה הזו תטופל כמו כל שאר הבקשות שנמצאות בטיפול. עקב בעיות במקביליות, יכול להיות שמבחינת ה-HAL, קריאה ל- process_capture_request()‎ תתחיל אחרי שהפעלת ה-flush, אבל היא עדיין לא תחזיר תשובה. אם קריאה כזו מתרחשת לפני שה-HAL מקבל את ההחזרה של flush()‎ , הוא צריך להתייחס לבקשת הצילום החדשה כמו לבקשות אחרות בהמתנה בזמן אמת (ראו בקטע 4 בהמשך).

באופן ספציפי, ה-HAL חייב לעמוד בדרישות הבאות במקרים שונים:

  1. לצילום שה-HAL לא יכול לבטל או לעצור, והוא יושלם באופן רגיל על ידי ה-HAL. כלומר, ה-HAL יכול לשלוח את האירועים shutter/notify ו-process_capture_result ואת המאגרים כרגיל.
  2. לגבי בקשות בהמתנה שלא בוצע בהן עיבוד, ה-HAL צריך להפעיל את ההודעה 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 עם מטא-נתונים שאינם null.

  3. לבקשות בהמתנה שהושלמו חלקית, שלא יהיו בהן כל מאגרי הפלט או שאולי חסרים להן מטא-נתונים, ה-HAL צריך לפעול לפי השלבים הבאים:

    3.1. צריך לקרוא ל-notify עם CAMERA3_MSG_ERROR_RESULT אם חלק מהמטא-נתונים הצפויים של התוצאה (כלומר מטא-נתון חלקי אחד או יותר) לא יהיו זמינים לצילום.

    3.2. קוראים ל-notify עם CAMERA3_MSG_ERROR_BUFFER לכל מאגר נתונים שלא יופק לצורך הצילום.

    3.3 קוראים ל-notify עם 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()‎ , צריך להתייחס לבקשת הצילום שסופקה על ידי הקריאה המאוחרת ל-process_capture_request‎ כמו לבקשה בהמתנה במקרה מס' 2 שלמעלה.

flush() צריך לחזור רק כשאין יותר מאגרים או בקשות לא מטופלות ב-HAL. המסגרת עשויה להפעיל את configure_streams (מכיוון שמצב ה-HAL נמצא עכשיו במצב רגיעה) או להנפיק בקשות חדשות.

שימו לב: מספיק לתמוך רק בתרחישים שבהם התוצאה היא הצלחה מלאה או כישלון מלא. עם זאת, מומלץ מאוד לתמוך גם במקרים של כשל חלקי, כי זה יכול לשפר את הביצועים הכוללים של קריאת ה-flush.

דרישות הביצועים:

ה-HAL אמור לחזור מהקריאה הזו תוך 100 אלפיות השנייה, והוא חייב לחזור מהקריאה הזו תוך 1,000 אלפיות השנייה. בנוסף, הקריאה הזו לא יכולה להיות חסומה למשך זמן ארוך יותר מזמן האחזור של צינור עיבוד הנתונים (לפי ההגדרה שמפורטת ב-S7).

פרטי הגרסה:

זמינה רק אם גרסת המכשיר היא ‎ >= CAMERA_DEVICE_API_VERSION_3_1.

ערכים שמוחזרים:

0: לאחר שטיפה מוצלחת של HAL המצלמה.

-EINVAL: אם הקלט לא תקין (המכשיר לא תקין).

-ENODEV: אם במכשיר המצלמה אירעה שגיאה חמורה. אחרי שהשגיאה הזו מוחזרת, המערכת יכולה להפעיל רק את השיטה close().

ההגדרה מופיעה בשורה 3077 בקובץ camera3.h .

void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, vendor_tag_query_ops_t *ops)

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 .

int(* initialize)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops)

initialize:

אתחול חד-פעמי להעברת מצביעים של פונקציות קריאה חוזרת של מסגרת ל-HAL. הקריאה תתבצע פעם אחת אחרי קריאה מוצלחת ל-open(), לפני שיהיו קריאות לפונקציות אחרות במבנה camera3_device_ops .

דרישות הביצועים:

זו צריכה להיות קריאה לא חוסמת. ה-HAL אמור לחזור מהקריאה הזו תוך 5ms, וצריך לחזור מהקריאה הזו תוך 10ms.

ערכים שמוחזרים:

0: לאחר אתחול מוצלח

-ENODEV: אם האתחול נכשל. לאחר מכן, המערכת תוכל לקרוא רק ל-close()‎.

ההגדרה מופיעה בשורה 2530 בקובץ camera3.h .

int(* process_capture_request)(const struct camera3_device *, camera3_capture_request_t *request)

process_capture_request:

שולחים בקשה חדשה לצילום ל-HAL. ה-HAL לא אמור לחזור מהקריאה הזו עד שהוא יהיה מוכן לקבל את הבקשה הבאה לעיבוד. המערכת תבצע רק קריאה אחת process_capture_request()‎ בכל פעם, והקריאות יבוצעו מאותו חוט. הקריאה הבאה ל- process_capture_request()‎ תתבצע ברגע שיהיו זמינים בקשה חדשה ומאגרי הנתונים המשויכים שלה. בתרחיש רגיל של תצוגה מקדימה, המשמעות היא שהמסגרת תקרא שוב לפונקציה כמעט באופן מיידי.

עיבוד הבקשה בפועל הוא אסינכרוני, ותוצאות הצילום מוחזרות על ידי HAL באמצעות הקריאה process_capture_result(). כדי לבצע את הקריאה הזו, המטא-נתונים של התוצאה צריכים להיות זמינים, אבל מאגרי הפלט עשויים לספק רק גדרות סנכרון להמתנה. צפויות להישלח כמה בקשות בו-זמנית כדי לשמור על קצב הפריימים המלא של הפלט.

המערכת שומרת על הבעלות על מבנה הבקשה. הוא תקף רק במהלך הקריאה הזו. מכשיר ה-HAL צריך ליצור עותקים של המידע שהוא צריך לשמור לצורך עיבוד הצילום. ה-HAL אחראי להמתנה על המחסומים של המאגרים, לסגירתם ולהחזרת הלחצנים של המאגרים למסגרת.

ה-HAL צריך לכתוב את מתאר הקובץ של גדר הסנכרון של שחרור מאגר הקלט ל-input_buffer->release_fence, אם הערך של input_buffer הוא לא NULL. אם ה-HAL מחזיר את הערך -1 למחסום הסנכרון של שחרור מאגר הקלט, המסגרת יכולה לעשות שימוש חוזר מיידי במאגר הקלט. אחרת, המסגרת תמתין לגבול הסנכרון לפני מילוי מחדש של מאגר הקלט ושימוש חוזר בו.

>= CAMERA_DEVICE_API_VERSION_3_2:

מאגרי הנתונים להזנה/פלט שסופקו על ידי המסגרת בכל בקשה עשויים להיות חדשים לגמרי (ולא נראו בעבר על ידי ה-HAL).

שיקולי ביצועים:

הטיפול במאגר חדש צריך להיות קל מאוד, ולא אמורה להיות פגיעה בקצב הפריימים או רעידות בפריימים.

הקריאה הזו צריכה לחזור מהר מספיק כדי להבטיח שאפשר לשמור על קצב הפריימים המבוקש, במיוחד במקרים של סטרימינג (הגדרות האיכות של עיבוד הנתונים לאחר העיבוד מוגדרות ל'מהיר'). ה-HAL צריך להחזיר את הקריאה הזו במרווח של פריימים אחד, וצריך לחזור מהקריאה הזו במרווח של 4 פריימים.

ערכים שמוחזרים:

0: תחילת העיבוד של בקשת הצילום הושלמה בהצלחה

-EINVAL: אם הקלט לא תקין (ההגדרות הן NULL כשלא מותר, יש 0 מאגרי פלט וכו') ולא ניתן להתחיל את עיבוד הצילום. כדי לטפל בכשלים במהלך עיבוד הבקשה, צריך לבצע קריאה ל- camera3_callback_ops_t.notify()‎ . במקרה של השגיאה הזו, המסגרת תישאר אחראית על המחסומים של מאגרי הנתונים של הסטרימינג ועל הלחצנים של המאגרים. ה-HAL לא צריך לסגור את המחסומים או להחזיר את המאגרים האלה באמצעות process_capture_result.

-ENODEV: אם במכשיר המצלמה אירעה שגיאה חמורה. אחרי שהשגיאה הזו מוחזרת, המערכת יכולה להפעיל רק את השיטה close().

ההגדרה מופיעה בשורה 2928 בקובץ camera3.h .

int(* register_stream_buffers)(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set)

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

הוצא משימוש. לא יתבצע קריאה ל-method הזה, וצריך להגדיר אותו כ-NULL.

<= CAMERA_DEVICE_API_VERSION_3_1:

רישום מאגרי נתונים זמניים (buffers) של סטרימינג נתון במכשיר ה-HAL. המערכת מפעילה את השיטה הזו אחרי ששידור חדש מוגדר על ידי configure_streams, ולפני שמאגרים מהשידור הזה נכללים בבקשת הקלטה. אם אותו שידור מופיע בקריאה configure_streams() הבאה, לא תתבצע קריאה חוזרת של register_stream_buffers לשידור הזה.

המסגרת לא צריכה לרשום מאגרים לכל הסטרימינגים שהוגדרו לפני שהיא שולחת את בקשת הצילום הראשונה. כך אפשר להפעיל במהירות תצוגה מקדימה (או תרחישים דומים) בזמן שהקצאת משאבים לשידורים אחרים עדיין מתבצעת.

השיטה הזו נועדה לאפשר למכשיר ה-HAL למפות את המאגרים או להכין אותם באופן אחר לשימוש מאוחר יותר. מאגרי הנתונים (buffers) שיועברו כבר יהיו נעולים לשימוש. בסיום השיחה, כל המאגרים צריכים להיות מוכנים להחזרה לשידור. הארגומנט buffer_set תקף רק למשך הקריאה הזו.

אם פורמט הסטרימינג הוגדר כ-HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, ה-HAL של המצלמה צריך לבדוק את מאגרי הנתונים המועברים כאן כדי לקבוע אם יש מידע על פורמט הפיקסלים שהוא פרטי לפלטפורמה.

דרישות הביצועים:

זו צריכה להיות קריאה לא חוסמת. ה-HAL אמור לחזור מהקריאה הזו תוך 1ms, וצריך לחזור מהקריאה הזו תוך 5ms.

ערכים שמוחזרים:

0: לאחר רישום מוצלח של מאגרי הנתונים החדשים של הסטרימינג

-EINVAL: אם ה-stream_buffer_set לא מתייחס למקור נתונים פעיל חוקי, או אם מערך המאגרים לא חוקי.

-ENOMEM: אם אירעה שגיאה ברישום המאגרים. המסגרת צריכה להתייחס לכל מאגרי הנתונים של הסטרימינג כאל מאגרים לא רשומים, ותוכל לנסות לרשום אותם שוב מאוחר יותר.

-ENODEV: אם יש שגיאה קטלנית והמכשיר לא פועל יותר. רק אחרי שהשגיאה הזו מוחזרת, ה-framework יכול לקרוא ל-close() בהצלחה.

ההגדרה מופיעה בשורה 2823 בקובץ camera3.h .

void* reserved[8]

ההגדרה מופיעה בשורה 3080 בקובץ camera3.h .

התיעוד של המבנה הזה נוצר מהקובץ הבא: