Fuchsia.sysmem

BufferCollection 是由參與者直接連線至 sysmem re，邏輯 BufferCollection邏輯 BufferCollection 通常共用於與其他參與者一起討論換句話說，BufferCollection 的例項介面是「邏輯緩衝區集合」的檢視畫面。

此連結有助於非同步指出邏輯 BufferCollection 已填入緩衝區。

此外，伺服器還會指示用戶端關閉管道用戶端應關閉來自請盡快收集緩衝區。

此外，這個介面日後可能允許在其他還可能允許某些限制學位。

這個介面未來可能允許每個 VM 擁有超過 64 個 VMO 帳號代碼 BufferCollection，但目前上限為 64 個。

這個介面日後可能會允許配置/取消配置單一緩衝區。

部分發起者可能會等待一小段時間，直到所有的舊邏輯 BufferCollection VMO 控制代碼已關閉 (或直到短時間內結束) )，這樣有助於控制避免記憶體分段遭到破壞，並避免新舊集合產品系列的內容可以夠大，值得注意避免時間重疊 (及時)。

已淘汰：23 新增：7

AttachLifetimeTracking

AttachLifetimeTracking:

AttachLifetimeTracking() 旨在讓用戶端等到舊邏輯緩衝區集合已完全或大部分交易嘗試分配新的邏輯緩衝區集合

將事件配對端點附加至邏輯緩衝區集合，分配的緩衝區數量時，系統就會關閉 server_end 則會降至「buffers_remaining」。Server_end 直到此時間過後才會關閉邏輯分配作業已完成

如果邏輯分配失敗，例如附加子樹狀結構 (使用 AttachToken()) 故障時，server_end 會在失敗期間關閉，不論是否可能分配到整體邏輯中的緩衝區數量緩衝區收集。

這個事件顯示的生命週期包含非同步清理而這項非同步清理作業必須 VMO 緩衝區的容器擁有者關閉了這些 VMO 控制代碼。因此，客戶應該小心不要永遠被封鎖，尤其是在對使用邏輯緩衝區集合的參與者較不信任或較不可靠

buffers_remaining 參數允許 buffers_remaining 緩衝區完整釋放。非常有用我們會刻意忽略已知數量的緩衝區因此您可以繼續使用資料，例如為了保留 UI 中顯示的最新可用影片圖片 (包含影片) 使用的是受保護的輸出緩衝區這不在 BufferCollection 介面 (至少目前至少) 以判斷有多少緩衝區可能會在沒有關閉的情況下保留，但通常位於範圍內 0 至 2。

這項機制應與提供類似的 AttachLifetimeTracking() 機制，也可以將同一個事件傳送至多個 AttachLifetimeTracking() 在整個生命週期內，ZX_EVENTPAIR_PEER_CLOSED 就會發出信號符合條件 (所有重複項目的擁有者都關閉了帳號代碼。

附件無法取消。結尾是事件配對就不會從待處理連結數量減去。

關閉用戶端不會導致伺服器執行任何動作。如果伺服器完全監聽用戶端的事件，僅限偵錯記錄。

伺服器刻意不「信任」任何位元數用戶端。這項機制刻意僅使用 ZX_EVENTPAIR_PEER_CLOSED 且無法提早觸發，且只有在所有控點時才會觸發至 server_end 已關閉。與任何一項用戶端應可正常忽略其他信號位元在事件組合的兩端或其對等端傳送位元。

Server_end 可能缺少 ZX_RIGHT_SIGNAL 或 ZX_RIGHT_SIGNAL_PEER，但必須具有 ZX_RIGHT_DUPLICATE (且必須具備 ZX_RIGHT_TRANSFER 才能而不會導致 CodecFactory 管道故障)。

要求

名稱	類型
`server_end`	`handle<eventpair>`
`buffers_remaining`	`uint32`

AttachToken

建立新符記，嘗試將新參與者加入現有參與者集合，若現有集合的緩衝區數量、限制且參與者允許

這有助於取代失敗的參與者，和/或在緩衝區後新增/重新新增參與者

未附加的權杖 / 集合未套用至附加符記的父項。失敗作業會從正常狀態傳播做為可補救憑證的子項。失敗如果附加子項，子發布商就無法取得其上層發布商。或子項可付款，且在符合邏輯的邏輯後發生分配速度。

在某些情況下，發起人可能會選擇一開始就使用殘款呼叫者的指定符記導致該參與者的實例發生錯誤，而在該執行個體的取得透過 AttachToken() 建立的符記。

BufferCollectionToken 用戶端端的視角權杖的運作管道與任何其他符記相同客戶可以視需要複製權杖，並將權杖傳送至不同的上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作權杖應轉換為 BufferCollection 管道照常呼叫 BindSharedCollection()。SetConstraints() 應會在 BufferCollection 管道上呼叫

waitForBuffersAllocations() 的成功結果代表新的使用現有的緩衝區集合，已建立的 BufferCollectionInfo 包括圖片格式限制，以及以及其緩衝數失敗結果代表新的無法使用現有的緩衝區集合及其已經根據邏輯配置的參與者。如果建立新的集合，可能會允許所有參與者限制條件 (假設已使用 SetDispensable()) AttachToken() 的標頭，或使用一般符記。

使用 AttachToken() 建立的權杖會執行限制條件匯總緩衝區集合中目前生效的所有限制條件，再加上考慮附加的符記，以及附加在且並非本身是附加的符記

將 buffer_count 分配給 min_buffer_count_for_camping 等為按順序優先，但子項無法在邏輯上分配所有父項都送出了 SetConstraints()。

另請參閱 SetDispensable()，相較於 AttachToken()，建立的符記 + 子項會參與限制匯總。

新建立的憑證必須在新的 sysmem 之前進行 Sync() 至 sysmem 也可傳到 BindSharedCollection()。新的並可透過 BufferCollection.Sync() 完成 BufferCollection.或是新舊版本的 BufferCollectionToken.Sync() 權杖也適用您可以在下列之後啟動 BufferCollectionToken.Sync() 任何 BufferCollectionToken.Duplicate() 訊息會透過以便同時將其他權杖同步到 sysmem 單趟往返行程

這些值的 copyright_attenuation_mask 不會導致任何注意力 (注意 (注意： 0 並不在這份清單中；0 會在系統記錄中顯示「ERROR」可協助診斷用戶端程式碼中的錯誤)：

ZX_RIGHT_SAME_RIGHTS (建議)
0xFFFFFFFF (適合在計算注意力遮罩時)

要求

名稱	類型
`rights_attenuation_mask`	`uint32`
`token_request`	`server_end<BufferCollectionToken>`

CheckBuffersAllocated

如果緩衝區集合已分配或失敗，或 ZX_ERR_UNAVAILABLE 表示 waitForBuffersAllocations 會封鎖。

要求

<空白>

回應

名稱	類型
`status`	`zx/Status`

關閉

在 BufferCollectionToken 管道上：

一般而言，參與者會將 BufferCollectionToken 轉換為 BufferCollection 檢視，但參與者也可以自由使用 Close() 然後立即關閉管道，或是稍後在否則將引發邏輯緩衝區無法收集。通常與預期外的權杖管道聯絡會導致邏輯緩衝區收集失敗 ( 與 AttachToken() 或 SetDispensable() 相關的情況)。

在 BufferCollection 管道上：

根據預設，伺服器會處理 BufferCollection 的非預期錯誤導致整個邏輯緩衝區集合失敗我們其中一部分是可以加速關閉 VMO 控制代碼，在有參與者時收回記憶體失敗。參與者想要徹底關閉 BufferCollection 不會導致邏輯緩衝區收集失敗可在 BufferCollection 的用戶端結束時傳送 Close() 管道。如果這是最後一個 BufferCollection 檢視畫面，最愛仍會消失Close() 可以早於或晚於 SetConstraints()。如果在 SetConstraints() 之前，則緩衝區集合進行分配時，不需要受限於這個節點的限制如果在 SetConstraints() 之後，系統會保留並匯總限制以及任何後續的邏輯分配管道連結。

在 BufferCollectionTokenGroup 管道上：

根據預設，BufferCollectionTokenGroup 發生非預期的失敗情形 BufferCollectionTokenGroup 的觸發失敗，並不會直接套用至父項關閉 BufferCollectionTokenGroup 而不會失敗邏輯群組或傳播失敗關閉管道用戶端端點之前的 Close()。

如果在 AllChildrenPresent() 之前發生 Close()，即使 Close() 無法擷取 sysmem，請確認所有相關的子項是否都出現，所以內容模糊不清是否將所有相關限制條件提供給 sysmem)。如果 Close() 發生在 AllChildrenPresent() 之後，子及其所有限制維持不變 (就像 BufferCollectionTokenGroup 管道仍為開啟狀態)，然後不會觸發或傳播失敗

要求

<空白>

GetAuxBuffers

已移除：23 已淘汰：9

要求

<空白>

回應

名稱	類型
`status`	`zx/Status`
`buffer_collection_info_aux_buffers`	`BufferCollectionInfo_2`

GetNodeRef

此函式會獲得事件控制代碼，可用來做為在任何節點上呼叫 IsAlternativeFor()。但用戶端無法在此帳號代碼僅應做為證明用戶端從這個節點取得此控點。

由於這是一個 get 集合，所以兩個執行個體之間不需要 Sync() GetNodeRef() 與 IsAlternativeFor() 的呼叫，即使兩次呼叫而且可能位於不同的管道

另請參閱 IsAlternativeFor()。

要求

<空白>

回應

名稱	類型
`node_ref`	`handle<event>`

IsAlternateFor

這會檢查呼叫節點是否位於根擁有常見父項 BufferCollectionTokenGroup 的不同子權杖就會引發這個事件。

這場通話旨在協助解決許可控制資料重複的問題，以及偵錯。

必須使用 Pod 的 GetNodeRef() 取得 node_ref BufferCollectionToken、BufferCollection 或 BufferCollectionTokenGroup。

node_ref 可以是重複的控制代碼；不需要呼叫每次呼叫 IsAlternativeFor() 時，都要取得 GetNodeRef()。

如果呼叫權杖實際上可能根本無效，權杖的可能惡意/不信任的提供者，呼叫先驗證 VerifyBufferCollectionToken() 如果 IsAlternativeFor() 因為呼叫而沒有回應，就會無限期停滯符記不是實際符記 (實際上並非與 sysmem 通訊)。其他選項就是先使用這個符記呼叫 BindSharedCollection 驗證權杖，並將權杖轉換為 BufferCollection，然後呼叫 BufferCollection IsAlternativeFor() 呼叫。

錯誤值：

ZX_ERR_NOT_FOUND 表示在相同邏輯中找不到 node_ref 做為呼叫節點邏輯分配之前也就是在相同的邏輯配置子樹狀結構中 node_ref 從來不是這個邏輯緩衝區集合的一部分，因為邏輯分配之前，所有進入存在的 node_refs 仍存在至少直到邏輯分配時間 (包含使用者曾使用 Close() 並關閉頻道)，而且 ZX_ERR_NOT_FOUND 但此節點的管道仍需連結伺服器如果整個邏輯分配期間失敗。邏輯分配之後或採用不同的邏輯分配後這個錯誤可能有其他可能的原因。適用對象例如其他邏輯分配示例 (與這個節點分隔) AttachToken() 或 SetDispensable() 的邏輯分配) 可能會失敗刪除這些節點的子樹狀結構或 BufferCollectionTokenGroup 其中的子樹狀結構和子樹狀結構可能會 node_ref 會導致系統刪除 node_ref 節點。唯一時間 sysmem 會在節點沒有對應管道後保留節點就是使用 Close()，且節點的子樹狀結構尚未失敗時。這項錯誤的另一個原因是 node_ref 是事件配對控制代碼但這並不是真的是 node_ref GetNodeRef().

ZX_ERR_INVALID_ARGS 代表呼叫端傳遞的 node_ref 不是技藝控制代碼，或者沒有預知所需的權利 node_ref.

這次呼叫不會傳回其他失敗的狀態碼。不過 sysmem 之後可能會加入其他程式碼，因此用戶端應該合理的預設處理方式。

成功時，is_sub 具有以下意義：

true - 呼叫節點與呼叫節點之間共同擁有的第一個父項節點 node_ref 節點是 BufferCollectionTokenGroup也就是說呼叫的 Node 及 node_ref 節點「不」同時具備而 sysmem 會選擇其中一個限制 - 絕對不能兩者這是因為只有一個子的子系在邏輯分配期間選取 BufferCollectionTokenGroup 導致單一子項的子樹狀結構中匯總。
false - 呼叫的 Node 與 node_ref Node 不是 BufferCollectionTokenGroup。目前，因此彼此相同的第一個父項節點 BufferCollectionToken 或 BufferCollection (無論 Close()ed 或 Close()ed)。也就是說，發出呼叫的節點 node_ref 節點在處理期間「可能」同時套用這兩種限制條件限制邏輯分配匯總(如果兩個節點皆有) 是由相關父項 BufferCollectionTokenGroup 所選取。在這個例子中，沒有任何 BufferCollectionTokenGroup 會這會直接防止同時選取兩個節點限制兩者的匯總，但即使為 false、其中一個或兩者皆可若節點一或同時存在，則仍可能被排除考慮節點具有直接或間接父項 BufferCollectionTokenGroup 這個子樹狀結構會選取呼叫 Node.js 或 node_ref 節點

要求

名稱	類型
`node_ref`	`handle<event>`

回應

名稱	類型
`payload`	`Node_IsAlternateFor_Result`

SetConstraints

將 BufferCollectionConstraints 提供給邏輯 BufferCollection。

參與者只能呼叫 SetConstraints() 一次。

發起人有時只是為了希望留意是否成功填入/失敗，以及填入緩衝區和 zx.Status 會在失敗時立即啟動在此情況下，has_constraints 可以是 false，且系統會忽略 constraints。

系統不會將 VMO 控制代碼提供給傳送空值的用戶端限制 - 可能意味著無益的發起人 VMO 控制代碼。沒有 VMO 控制代碼無法導致啟動器無法調整緩衝區中哪些部分被視為有效且相似，但發起人不能將 VMO 控制代碼保持開啟，藉此防止邏輯不自然在邏輯 BufferCollection 的需求下清除緩衝區集合無論發起人是否參與。

對於要嘗試的緩衝區總數， BufferCollection 用戶端管道需先呼叫 SetConstraints() sysmem 會嘗試分配緩衝區。

has_constraints 設為 false，表示限制條件實際上為空值；系統會忽略 constraints。空值限制的傳送者不會取得任何 BufferCollectionInfo 中的 VMO 會控制代碼，但您還是可以查看緩衝區，並且仍可根據本身的緩衝區 buffer_index.

constraints 是緩衝區集合的限制。

要求

名稱	類型
`has_constraints`	`bool`
`constraints`	`BufferCollectionConstraints`

SetConstraintsAuxBuffers

已移除：23 已淘汰：9

要求

名稱	類型
`constraints`	`BufferCollectionConstraintsAuxBuffers`

SetDebugClientInfo

啟用詳細記錄功能時也會使用 (請參閱 SetVerboseLogging()) 指出哪一位客戶最先關閉頻道，而子樹狀結構故障 (如果子樹狀結構的用途為但如果時間比預期更早用戶管道專屬名稱有助於診斷失敗的原因個人的觀點)。

預設 (除非覆寫此訊息或使用 Allocator.SetDebugClientInfo()) 之後，節點會複製節點中的資訊子項節點建立時。雖然這可以通常適合每位參與者 Node.SetDebugClientInfo() 或 Allocator.SetDebugClientInfo() 以保留與當前客戶直接相關的資訊此外，SetVerboseLogging() 可用於釐清節點是否懷疑節點可能含有資訊複製出的片段

要求

名稱	類型
`name`	`string[64]`
`id`	`uint64`

SetDebugTimeoutLogDeadline

如果並非所有用戶端都設定了限制 5 秒，Sysmem 會記錄一次警告建立集合後用戶端可以呼叫這個方法，將變更顯示記錄如果有多個用戶端設定了期限，未指定生效的期限。

要求

名稱	類型
`deadline`	`zx/Time`

SetName

為這個緩衝區集合中的 VMO 設定名稱。名稱可能會遭到截斷較短的內容這個名稱只會影響設定後分配的 VMO，也就是這個通話無法重新命名現有的 VMO。如果多個客戶設定不同名稱那麼優先順序較高的值勝出

要求

名稱	類型
`priority`	`uint32`
`name`	`string[64]`

SetVerboseLogging

詳細記錄包含透過每個 API 設定的 SetConstraints() 設定限制用戶端和透過 SetDebugClientInfo() 設定的資訊，以及節點的樹狀結構

在匯總作業期間，Symem 只會顯示單一行申訴失敗，只有匯總失敗的確切原因幾乎沒有背景資料雖然這通常足以診斷問題但系統原本就有用的設備稍小的改變通常在取得新的廣告素材時緩衝區集合首次運作尤其是節點的複雜樹狀結構，包含 AttachToken() 等項目 SetDispensable()、BufferCollectionTokenGroup 節點，以及相關聯的節點子樹狀結構，詳細記錄可能有助於診斷以及邏輯配置失敗的原因子樹狀結構的執行速度比預期更快。

額外記錄的用意是可接受從效能來看視角 (如果只在緩衝區集合較少的情況下啟用)。如果未追蹤錯誤，我們就不會傳送這則訊息。

如果太多參與者退出詳細記錄功能，我們最後可能會必須允許整個系統的 Symem 詳細記錄功能進行其他設定，避免對記錄散播太多內容，這則訊息。

基於刻意相關聯的政策，這對於部分節點來說可能是 NOP 與節點互動時，如果我們不信任該節點，而讓該節點開啟詳細內容。

要求

<空白>

同步

確認先前訊息，包括已成功收到伺服器端代碼、集合或群組

對非/之前的權杖呼叫 BufferCollectionToken.Sync() 有效的 sysmem 權杖可能導致 Sync() 永久停止運作。詳情請見驗證 BufferCollectionToken() 的方法之一，藉此降低可能性。成本另一種方法是將權杖傳遞至 BindSharedCollection()，在對 BufferCollection 交換權杖時，驗證權杖管道，就能使用 BufferCollection Sync()

執行 Sync() 之後，您就能放心傳送 token_request 的用戶端可供已知伺服器辨識的其他參與者則會傳送給 BindSharedCollection()。

其他選項包括等待各個 token.Duplicate() 完成個別 (在每個呼叫後使用單獨對 token.Sync() 的呼叫)，或憑證啟用後，對 BufferCollection 呼叫 Sync() 透過 BindSharedCollection() 取得 ID。

另一個緩解方法是避免在權杖上呼叫 Sync()，且而是處理 BufferCollection.Sync() 可能發生的失敗問題原始權杖無效。這個選項非常適合從觀點，但需要用戶端程式碼才能延遲傳送直到用戶端程式碼轉換完成後，再從這個權杖複製而來的權杖將權杖複製到 BufferCollection BufferCollection.Sync() 的回應。

在可行的情況下，請改使用 BufferCollection.Sync() (請參閱上文)。如果 BufferCollection.Sync() 無法使用，呼叫端必須已經得知這個 Token 有效或 BufferCollectionToken.Sync() 。請參閱 VerifiedBufferCollectionToken() 檢查權杖如果權杖尚未確定 (是否有效) 有效，則優先效力。

要求

<空白>

回應

<空白>

WaitForBuffersAllocated

這項要求會在已分配緩衝區時完成，如果嘗試配置卻失敗，請列出失敗的詳細資料。

分配緩衝區前，必須發生以下情況：

邏輯 BufferCollectionToken 的所有 BufferCollectionToken 必須透過 BindSharedCollection() 啟用。
邏輯 BufferCollection 的所有 BufferCollection 都必須已將 SetConstraints() 傳送至這些物件

如果成功，則傳回 ZX_OK。如果要求有效，但無法傳回 ZX_ERR_NO_MEMORY，則會傳回 ZX_ERR_NO_MEMORY 而已完成遷移如果呼叫端未獲準，則傳回 ZX_ERR_ACCESS_DENIED 才能取得要求的緩衝區如果要求格式錯誤，則傳回 ZX_ERR_INVALID_ARGS。如果要求有效，但無法傳回 ZX_ERR_NOT_SUPPORTED，則傳回 ZX_ERR_NOT_SUPPORTED 可能是因硬體限製造成的

buffer_collection_info 有 VMO 帳號代碼和其他相關資訊。

要求

<空白>

回應

名稱	類型
`status`	`zx/Status`
`buffer_collection_info`	`BufferCollectionInfo_2`

BufferCollectionToken

BufferCollectionToken 並不是 BufferCollection 在緩衝區開始前，找出可能的共用 BufferCollection 。

我們使用 BufferCollectionToken 的管道，而非單一事件配對 (配對)，以便我們偵測參與者等錯誤狀況在創作時可能需要一點時間才能解決

fuchsia.sysmem.BufferCollectionToken 類型尚未淘汰，原因如下：目前也用於其他通訊協定，但 fuchsia.sysmem.BufferCollectionToken 已淘汰。提供權杖管道 fuchsia.sysmem.BufferCollectionToken 和 fuchsia.sysmem2.BufferCollectionToken

一旦其他通訊協定改用新的通訊協定，這個通訊協定就會遭到淘汰符記欄位變更為 fuchsia.sysmem2.BufferCollectionToken

新增：7

關閉

在 BufferCollectionToken 管道上：

在 BufferCollection 管道上：

在 BufferCollectionTokenGroup 管道上：

要求

<空白>

CreateBufferCollectionTokenGroup

大部分的 sysmem 用戶端和許多參與者都不需要留意這一點 BufferCollectionTokenGroup 的所有訊息或主題。

BufferCollectionTokenGroup 可用來在 N 個子項中建立 N「或」的 1 個符記匯總期間未選取的子項權杖失敗 (關閉)，對潛在參與者來說 BufferCollection 管道用戶端端點偵測到 PEER_CLOSED，因此允許參與者善加清理非最終的推測使用行為 (類似正常的 BufferCollection 伺服器結束) 邏輯緩衝區收集失敗時)。

查看通訊協定 BufferCollectionTokenGroup 的註解。

將為了達成這個目的做為群組的直接上層

group_request - BufferCollectionTokenGroup 管道的伺服器結束最終透過 sysmem 放送

已淘汰：23 新增：9

要求

名稱	類型
`group_request`	`server_end<BufferCollectionTokenGroup>`

複製

這個方法可在建立分享項目前新增參與者 BufferCollection.請只在不適合等待模型 Symem 的回應，做為每筆重複的一部分。

傳送一或多則 Duplicate() 訊息後，接著在傳送建立符記給其他參與者 (或其他 Allocator 頻道) 用戶端應傳送 Sync() 並等待其回應。Sync() 呼叫皆可在權杖上進行，或在接著將這個權杖傳遞至 BindSharedCollection()。這兩項服務都能確保伺服器知道在其他參與者透過不同的 Allocator 將權杖傳送至伺服器管道。

所有權杖都必須透過 BindSharedCollection() 或 Close() 產生，已成功建立 BufferCollection。

當用戶端呼叫 BindSharedCollection() 以 BufferCollectionToken，伺服器會處理所有 Duplicate() 訊息再關閉 BufferCollectionToken這樣一來，用戶端複製到 Duplicate()，並立即改用 BindSharedCollection，然後稍後轉移 token_request 的用戶端結束給其他參與者 - 伺服器會注意到 token_request 才認為這個 BufferCollectionToken 完全關閉。

這個遮罩中，rights_attenuation_mask 個權利位元的數值將為 0 缺少可透過用戶端用戶端取得的緩衝區 VMO 權利 token_request.發起人或中介商考量參與者可用的權利。請注意取得參與者原本沒有的權利。 ZX_RIGHT_SAME_RIGHTS 值可用於指定無都應套用提示

下列 Rights_attenuation_mask 的值對應的值不會吸引註意：

ZX_RIGHT_SAME_RIGHTS (建議)
0xFFFFFFFF (適合在計算注意力遮罩時)
0 (已淘汰 - 不使用 0：錯誤會移至記錄)

token_request 是 BufferCollectionToken 管道的伺服器端。此管道的用戶端等同於另一個參與者共用的緩衝區集合。

已淘汰：23 新增：7

要求

名稱	類型
`rights_attenuation_mask`	`uint32`
`token_request`	`server_end<BufferCollectionToken>`

DuplicateSync

這個方法可用來在建立共用的緩衝區集合。系統會為 rights_attenuation_masks 陣列。傳回值為用戶端直到每個新參與者權杖結束為止

如果呼叫權杖實際上可能並非有效權杖，權杖的可能惡意/不受信任的提供者，請考慮使用先驗證 VerifyBufferCollectionToken() 如果 DuplicateSync() 因呼叫問題而沒有回應，則會無限期停滯不會做為真實權杖

與 Duplicate() 不同，不需使用 Sync() (請參閱「通訊協定節點」) 呼叫此方法後。

所有權杖都必須透過 BindSharedCollection() 或 Close() 產生，已成功建立 BufferCollection。

在 rights_attenuation_masks 的每個項目中，權限位元均為零而不會在可透過相對應的傳回的符記。發起人或中介商考量參與者可用的權利。請注意取得參與者原本沒有的權利。 ZX_RIGHT_SAME_RIGHTS 值可用於指定無都應套用提示

已淘汰：23 新增：7

要求

名稱	類型
`rights_attenuation_masks`	`vector<zx/Rights>[64]`

回應

名稱	類型
`tokens`	`vector<BufferCollectionToken>[64]`

GetNodeRef

此函式會獲得事件控制代碼，可用來做為在任何節點上呼叫 IsAlternativeFor()。但用戶端無法在此帳號代碼僅應做為證明用戶端從這個節點取得此控點。

由於這是一個 get 集合，所以兩個執行個體之間不需要 Sync() GetNodeRef() 與 IsAlternativeFor() 的呼叫，即使兩次呼叫而且可能位於不同的管道

另請參閱 IsAlternativeFor()。

要求

<空白>

回應

名稱	類型
`node_ref`	`handle<event>`

IsAlternateFor

這會檢查呼叫節點是否位於根擁有常見父項 BufferCollectionTokenGroup 的不同子權杖就會引發這個事件。

這場通話旨在協助解決許可控制資料重複的問題，以及偵錯。

必須使用 Pod 的 GetNodeRef() 取得 node_ref BufferCollectionToken、BufferCollection 或 BufferCollectionTokenGroup。

node_ref 可以是重複的控制代碼；不需要呼叫每次呼叫 IsAlternativeFor() 時，都要取得 GetNodeRef()。

錯誤值：

ZX_ERR_INVALID_ARGS 代表呼叫端傳遞的 node_ref 不是技藝控制代碼，或者沒有預知所需的權利 node_ref.

這次呼叫不會傳回其他失敗的狀態碼。不過 sysmem 之後可能會加入其他程式碼，因此用戶端應該合理的預設處理方式。

成功時，is_sub 具有以下意義：

true - 呼叫節點與呼叫節點之間共同擁有的第一個父項節點 node_ref 節點是 BufferCollectionTokenGroup也就是說呼叫的 Node 及 node_ref 節點「不」同時具備而 sysmem 會選擇其中一個限制 - 絕對不能兩者這是因為只有一個子的子系在邏輯分配期間選取 BufferCollectionTokenGroup 導致單一子項的子樹狀結構中匯總。
false - 呼叫的 Node 與 node_ref Node 不是 BufferCollectionTokenGroup。目前，因此彼此相同的第一個父項節點 BufferCollectionToken 或 BufferCollection (無論 Close()ed 或 Close()ed)。也就是說，發出呼叫的節點 node_ref 節點在處理期間「可能」同時套用這兩種限制條件限制邏輯分配匯總(如果兩個節點皆有) 是由相關父項 BufferCollectionTokenGroup 所選取。在這個例子中，沒有任何 BufferCollectionTokenGroup 會這會直接防止同時選取兩個節點限制兩者的匯總，但即使為 false、其中一個或兩者皆可若節點一或同時存在，則仍可能被排除考慮節點具有直接或間接父項 BufferCollectionTokenGroup 這個子樹狀結構會選取呼叫 Node.js 或 node_ref 節點

要求

名稱	類型
`node_ref`	`handle<event>`

回應

名稱	類型
`payload`	`Node_IsAlternateFor_Result`

SetDebugClientInfo

要求

名稱	類型
`name`	`string[64]`
`id`	`uint64`

SetDebugTimeoutLogDeadline

要求

名稱	類型
`deadline`	`zx/Time`

SetDispensable

以邏輯方式分配緩衝區後，可永久權杖可能會失敗而不會導致父項失敗 (如果有的話)

可兌換的權杖會參與限制匯總，並在邏輯緩衝區分配之前如果一次性權杖失敗後，故障就會傳播至備用符記的父項。

邏輯分配後，可付款權杖故障 (或任何可付款權杖的子項) 不會套用至備用符記的父項。失敗作業會從正常狀態傳播做為可補救憑證的子項。失敗如果附加子項，子發布商就無法取得其上層發布商。或子項可付款，且在符合邏輯的邏輯後發生分配速度。

在參與者需要參與者協助時，可以使用一次性憑證提供限制，不過在緩衝區配置後，參與者就會失敗，而不會導致父項的緩衝區收集失敗

相反地，AttachToken() 可用來建立和父項一起參與限制匯總，隨時發生的失敗情形不會反映到父項提供限制條件並不會導致父項無法完成緩衝區分配方法

當用戶端使用這則訊息時，用戶端不應依賴用戶端自己的 BufferCollectionToken 或 BufferCollection 管道，因為任何 BufferCollectionToken 或 BufferCollection 用戶端使用 SetDispensable()，其他程序。因此，客戶應格外小心，就會發現該程序未能透過其他方式完成。

雖然您可以對 BufferCollectionTokenGroup 的直接子項，日後就無法替換失敗的可支付權杖，該權杖為群組的直接子項以及使用 AttachToken() 的新權杖 (因為沒有 AttachToken() 群組)。在此情況下，如要啟用 AttachToken() 取代模式，建立其他無折扣權杖 (節點)，做為直接子項並將現有的可付款憑證設為額外的權杖 (節點)這樣就能群組的直接子項則會有 BufferCollection.AttachToken() 來替換失敗的可付款權杖。

已經補償的權杖上的 SetDispensable() 是冪等的。

已淘汰：23 新增：7

要求

<空白>

SetName

要求

名稱	類型
`priority`	`uint32`
`name`	`string[64]`

SetVerboseLogging

詳細記錄包含透過每個 API 設定的 SetConstraints() 設定限制用戶端和透過 SetDebugClientInfo() 設定的資訊，以及節點的樹狀結構

額外記錄的用意是可接受從效能來看視角 (如果只在緩衝區集合較少的情況下啟用)。如果未追蹤錯誤，我們就不會傳送這則訊息。

如果太多參與者退出詳細記錄功能，我們最後可能會必須允許整個系統的 Symem 詳細記錄功能進行其他設定，避免對記錄散播太多內容，這則訊息。

基於刻意相關聯的政策，這對於部分節點來說可能是 NOP 與節點互動時，如果我們不信任該節點，而讓該節點開啟詳細內容。

要求

<空白>

同步

確認先前訊息，包括已成功收到伺服器端代碼、集合或群組

執行 Sync() 之後，您就能放心傳送 token_request 的用戶端可供已知伺服器辨識的其他參與者則會傳送給 BindSharedCollection()。

要求

<空白>

回應

<空白>

BufferCollectionTokenGroup

Symem 實作保證與邏輯 / 概念式模型如下：

和往常一樣，邏輯分配方式會考慮根層級和所有具有連至不傳輸 AttachToken() 的根層級根層級為 AttachToken() 權杖，以及所有與該資源相連結的節點未傳輸其他 AttachToken() 的子樹狀結構。這就是所謂的邏輯分配方式為修剪的子樹狀結構，或為精簡而修剪的子樹狀結構。

在限制匯總期間，系統會為每個 BufferCollectionTokenGroup 選取所有子項中的單一子權杖其餘孩子邏輯分配失敗，但所選的子項可能會成功。

整體邏輯中存在多個 BufferCollectionTokenGroup 時配置修剪的子樹狀結構，兩個群組的相對優先順序為相當於在 DFS 預購疊代時套用排序，家長比子項優先，並將子發布商的優先順序設為比右子孩子多

選取群組的特定子項時 (無論在進行限制匯總嘗試，或做為最終選擇時，如未選取群組的其他子項，系統可能會「隱藏」其他歸入未選取的子項。

在邏輯分配中，系統會先暫時嘗試匯總從優先順序最高的群組中選取子項 0，並從下一個子群組中選取子項 0 不受佈建設定隱藏的最高優先順序群組等等

如果匯總嘗試失敗，系統就會使用所有相同群組的序數 0 子項 (優先順序最低且不隱藏) 將佈建其序數的 1 子項 (接著是子 2) 依此類推如果將新的最低優先順序群組取消隱藏為臨時群組已更新，現在所有未隱藏的最低優先順序群組在變更佈建作業前，系統會按照順序考慮其子項加到優先級最低的群組因此，這和形成系統式列舉，列出所有可能的選擇組合按照計數方式更新優先順序最低的群組，會更頻繁地更新優先順序最高的群組與其實際嘗試等所有組合加以匯總後，即可略過哪些組合多半是多餘或對等項目，因為在未變更結果的情況下隱藏出來。

嘗試匯總不相等的選項組合繼續以這種方式執行，直到 (a) 所有匯總嘗試在此時整體邏輯分配失敗，或 (b) 直到嘗試匯總成功，在此情況下，系統會視需要只會嘗試一次根據首次成功後的緩衝區分配情形匯總失敗，整體邏輯分配作業會失敗 (沒有緩衝區分配重試 / 重新嘗試)。如果緩衝區分配成功 (或失敗邏輯分配成功

如果這種優先配置方式無法合理用於您的 Symem，請與 Sysmem 團隊聯絡，討論可能增加達成需求

請避免大量建立大量 BufferCollectionTokenGroup 邏輯分配，特別是整體子項數量眾多時尤其是在可合理預期匯總無法使用序數 0 子項，也可能包含後面的子項。三可以減少評估作業的複雜程度因失敗而找不到太多組子組合/選擇邏輯分配範圍超過一定 (相當高但非龐大) 上限當做群組子項組合/選項的條件。進階 (及其他功能) 複雜) 緩解措施並非實際必要值得增加的複雜性如果上限，請與 sysmem 人員聯絡或是如果您預期流量會成功只要設定成「自動重新啟動」和「在主機維護期間」選項即可

想在單一請求中使用多個 ImageFormatConstraint 可能的情況下，BufferCollectionConstraints (參與者只需搭配多種 Pixel 格式， Symem 選擇使用哪種 PixelFormat 參與者)。

與 BufferCollectionToken 和 BufferCollection 類似，關閉如果 BufferCollectionTokenGroup 管道沒有先傳送 Close()，就會導致邏輯緩衝區收集失敗 (如果使用 SetDispensable() 或 AttachToken() 以及 BufferCollectionTokenGroup 未傳播至該節點下的子樹狀結構父項)。

已淘汰：23 新增：9

AllChildrenPresent

AllChildrenPresent()

建立所有子項後，用戶端必須呼叫 AllChildrenPresent() 通知 sysmem，不要再建立任何子項並在何時適合開始匯總限制。

如果要傳送 Close()，則應在之後才傳送 AllChildrenPresent() 而故障，並且若無法呼叫群組的父項，仍會觸發。

要求

<空白>

關閉

在 BufferCollectionToken 管道上：

在 BufferCollection 管道上：

在 BufferCollectionTokenGroup 管道上：

要求

<空白>

CreateChild

建立子項權杖。將這個權杖的用戶端結尾傳遞至 BindSharedCollection()，CreateChild() 在這通常代表交易不會十分要求關聯語意或者，用戶端可以使用 CreateChildrenSync()，基本上就是包括 Sync()

token_request - 新憑證管道的伺服器端點。

Rights_attenuation_mask - 如果 ZX_RIGHT_SAME_RIGHTS 是已建立的 Token 可讓持有人取得與父項權杖相同的緩衝區 (群組) 擁有。

要求

名稱	類型
`payload`	`BufferCollectionTokenGroupCreateChildRequest`

CreateChildrenSync

以同步方式一次建立 1 或多個子項符記。對比 CreateChild()，傳送接收回傳憑證到 BindSharedCollection() 的呼叫。

Rights_attentuation_mask 的大小決定已建立子權杖

較低索引的子符記優先順序較高 (嘗試越早) 索引子項符記

就所有子項符記而言，成功的匯總作業只會選擇一個所有已建立的子項中 (涵蓋於可能會多次呼叫 CreateChild() 和 CreateChildrenSync())。

每個群組允許的兒童總數上限，以及整體樹狀結構 (根層級) 中的節點數量設有限制無法透過這些通訊協定進行設定

要求

名稱	類型
`rights_attenuation_masks`	`vector<zx/Rights>[64]`

回應

名稱	類型
`tokens`	`vector<BufferCollectionToken>[64]`

GetNodeRef

此函式會獲得事件控制代碼，可用來做為在任何節點上呼叫 IsAlternativeFor()。但用戶端無法在此帳號代碼僅應做為證明用戶端從這個節點取得此控點。

由於這是一個 get 集合，所以兩個執行個體之間不需要 Sync() GetNodeRef() 與 IsAlternativeFor() 的呼叫，即使兩次呼叫而且可能位於不同的管道

另請參閱 IsAlternativeFor()。

要求

<空白>

回應

名稱	類型
`node_ref`	`handle<event>`

IsAlternateFor

這會檢查呼叫節點是否位於根擁有常見父項 BufferCollectionTokenGroup 的不同子權杖就會引發這個事件。

這場通話旨在協助解決許可控制資料重複的問題，以及偵錯。

必須使用 Pod 的 GetNodeRef() 取得 node_ref BufferCollectionToken、BufferCollection 或 BufferCollectionTokenGroup。

node_ref 可以是重複的控制代碼；不需要呼叫每次呼叫 IsAlternativeFor() 時，都要取得 GetNodeRef()。

錯誤值：

ZX_ERR_INVALID_ARGS 代表呼叫端傳遞的 node_ref 不是技藝控制代碼，或者沒有預知所需的權利 node_ref.

這次呼叫不會傳回其他失敗的狀態碼。不過 sysmem 之後可能會加入其他程式碼，因此用戶端應該合理的預設處理方式。

成功時，is_sub 具有以下意義：

true - 呼叫節點與呼叫節點之間共同擁有的第一個父項節點 node_ref 節點是 BufferCollectionTokenGroup也就是說呼叫的 Node 及 node_ref 節點「不」同時具備而 sysmem 會選擇其中一個限制 - 絕對不能兩者這是因為只有一個子的子系在邏輯分配期間選取 BufferCollectionTokenGroup 導致單一子項的子樹狀結構中匯總。
false - 呼叫的 Node 與 node_ref Node 不是 BufferCollectionTokenGroup。目前，因此彼此相同的第一個父項節點 BufferCollectionToken 或 BufferCollection (無論 Close()ed 或 Close()ed)。也就是說，發出呼叫的節點 node_ref 節點在處理期間「可能」同時套用這兩種限制條件限制邏輯分配匯總(如果兩個節點皆有) 是由相關父項 BufferCollectionTokenGroup 所選取。在這個例子中，沒有任何 BufferCollectionTokenGroup 會這會直接防止同時選取兩個節點限制兩者的匯總，但即使為 false、其中一個或兩者皆可若節點一或同時存在，則仍可能被排除考慮節點具有直接或間接父項 BufferCollectionTokenGroup 這個子樹狀結構會選取呼叫 Node.js 或 node_ref 節點

要求

名稱	類型
`node_ref`	`handle<event>`

回應

名稱	類型
`payload`	`Node_IsAlternateFor_Result`

SetDebugClientInfo

要求

名稱	類型
`name`	`string[64]`
`id`	`uint64`

SetDebugTimeoutLogDeadline

要求

名稱	類型
`deadline`	`zx/Time`

SetName

要求

名稱	類型
`priority`	`uint32`
`name`	`string[64]`

SetVerboseLogging

詳細記錄包含透過每個 API 設定的 SetConstraints() 設定限制用戶端和透過 SetDebugClientInfo() 設定的資訊，以及節點的樹狀結構

額外記錄的用意是可接受從效能來看視角 (如果只在緩衝區集合較少的情況下啟用)。如果未追蹤錯誤，我們就不會傳送這則訊息。

如果太多參與者退出詳細記錄功能，我們最後可能會必須允許整個系統的 Symem 詳細記錄功能進行其他設定，避免對記錄散播太多內容，這則訊息。

基於刻意相關聯的政策，這對於部分節點來說可能是 NOP 與節點互動時，如果我們不信任該節點，而讓該節點開啟詳細內容。

要求

<空白>

同步

確認先前訊息，包括已成功收到伺服器端代碼、集合或群組

執行 Sync() 之後，您就能放心傳送 token_request 的用戶端可供已知伺服器辨識的其他參與者則會傳送給 BindSharedCollection()。

要求

<空白>

回應

<空白>

DriverConnector

定義於 fuchsia.sysmem/driver_connector.fidl

在這個介面上為驅動程式庫建立管道後 (通常是之後，這個介面就能以非同步方式傳送由驅動程式庫提供的分配器管道。

目前唯一透過一般開發主機 FIDL 直接提供的 FIDL 介面這是由 sysmem 驅動程式分派程式碼的介面其他 Symem 介面主要是透過個別的分派程式碼提供才能以非同步的方式不必開著來回切換管道，也不需要管理頻道做為檔案描述元

https://fxbug.dev/42108063 追蹤的第二種因素是目前的開發主機分派程式碼不允許非同步處理請求，以便至少讓 BufferCollection 介面正常運作介麵包含要求在 devhost 執行其他參與者的限制。

已移除：23 已淘汰：9 新增：7

連線

這則單向訊息會在 Allocator 管道的伺服器端傳送。

「allocator_request」會由 Symem 驅動程式 (或管道提供關閉)。

要求

名稱	類型
`allocator_request`	`server_end<Allocator>`

SetAuxServiceDirectory

要求

名稱	類型
`service_directory`	`fuchsia.io/Directory`

節點

已淘汰：23 新增：9

關閉

在 BufferCollectionToken 管道上：

在 BufferCollection 管道上：

在 BufferCollectionTokenGroup 管道上：

要求

<空白>

GetNodeRef

此函式會獲得事件控制代碼，可用來做為在任何節點上呼叫 IsAlternativeFor()。但用戶端無法在此帳號代碼僅應做為證明用戶端從這個節點取得此控點。

由於這是一個 get 集合，所以兩個執行個體之間不需要 Sync() GetNodeRef() 與 IsAlternativeFor() 的呼叫，即使兩次呼叫而且可能位於不同的管道

另請參閱 IsAlternativeFor()。

要求

<空白>

回應

名稱	類型
`node_ref`	`handle<event>`

IsAlternateFor

這會檢查呼叫節點是否位於根擁有常見父項 BufferCollectionTokenGroup 的不同子權杖就會引發這個事件。

這場通話旨在協助解決許可控制資料重複的問題，以及偵錯。

必須使用 Pod 的 GetNodeRef() 取得 node_ref BufferCollectionToken、BufferCollection 或 BufferCollectionTokenGroup。

node_ref 可以是重複的控制代碼；不需要呼叫每次呼叫 IsAlternativeFor() 時，都要取得 GetNodeRef()。

錯誤值：

ZX_ERR_INVALID_ARGS 代表呼叫端傳遞的 node_ref 不是技藝控制代碼，或者沒有預知所需的權利 node_ref.

這次呼叫不會傳回其他失敗的狀態碼。不過 sysmem 之後可能會加入其他程式碼，因此用戶端應該合理的預設處理方式。

成功時，is_sub 具有以下意義：

true - 呼叫節點與呼叫節點之間共同擁有的第一個父項節點 node_ref 節點是 BufferCollectionTokenGroup也就是說呼叫的 Node 及 node_ref 節點「不」同時具備而 sysmem 會選擇其中一個限制 - 絕對不能兩者這是因為只有一個子的子系在邏輯分配期間選取 BufferCollectionTokenGroup 導致單一子項的子樹狀結構中匯總。
false - 呼叫的 Node 與 node_ref Node 不是 BufferCollectionTokenGroup。目前，因此彼此相同的第一個父項節點 BufferCollectionToken 或 BufferCollection (無論 Close()ed 或 Close()ed)。也就是說，發出呼叫的節點 node_ref 節點在處理期間「可能」同時套用這兩種限制條件限制邏輯分配匯總(如果兩個節點皆有) 是由相關父項 BufferCollectionTokenGroup 所選取。在這個例子中，沒有任何 BufferCollectionTokenGroup 會這會直接防止同時選取兩個節點限制兩者的匯總，但即使為 false、其中一個或兩者皆可若節點一或同時存在，則仍可能被排除考慮節點具有直接或間接父項 BufferCollectionTokenGroup 這個子樹狀結構會選取呼叫 Node.js 或 node_ref 節點

要求

名稱	類型
`node_ref`	`handle<event>`

回應

名稱	類型
`payload`	`Node_IsAlternateFor_Result`

SetDebugClientInfo

要求

名稱	類型
`name`	`string[64]`
`id`	`uint64`

SetDebugTimeoutLogDeadline

要求

名稱	類型
`deadline`	`zx/Time`

SetName

要求

名稱	類型
`priority`	`uint32`
`name`	`string[64]`

SetVerboseLogging

詳細記錄包含透過每個 API 設定的 SetConstraints() 設定限制用戶端和透過 SetDebugClientInfo() 設定的資訊，以及節點的樹狀結構

額外記錄的用意是可接受從效能來看視角 (如果只在緩衝區集合較少的情況下啟用)。如果未追蹤錯誤，我們就不會傳送這則訊息。

如果太多參與者退出詳細記錄功能，我們最後可能會必須允許整個系統的 Symem 詳細記錄功能進行其他設定，避免對記錄散播太多內容，這則訊息。

基於刻意相關聯的政策，這對於部分節點來說可能是 NOP 與節點互動時，如果我們不信任該節點，而讓該節點開啟詳細內容。

要求

<空白>

同步

確認先前訊息，包括已成功收到伺服器端代碼、集合或群組

執行 Sync() 之後，您就能放心傳送 token_request 的用戶端可供已知伺服器辨識的其他參與者則會傳送給 BindSharedCollection()。

要求

<空白>

回應

<空白>

SecureMem

在 fuchsia.sysmem/secure_mem.fidl 中定義

SecureMem

用戶端為 sysmem。伺服器是 Securemem 驅動程式庫

TEE - 受信任的執行環境。

REE - 豐富的執行環境。

啟用 sysmem 呼叫 Securemem 驅動程式庫，取得任何安全的堆積透過 TEE (或安全 mem 驅動程式) 設定，然後將透過 sysmem 設定的安全堆積。

目前，動態配置的安全堆積是透過 sysmem 設定，程式就會在啟動期間很早開始且能成功預約實體記憶體目前，固定位置安全堆積的設定方式是透過 TEE，因為管線是從系統啟動載入程式傳送到 TEE。不過，通訊協定刻意不考慮哪些堆積會動態分配以及固定位置

已淘汰：23 新增：7

AddSecureHeapPhysicalRange

這個從 Symem 到 Securemem 驅動程式庫的要求要新增的範圍，以透過 sysmem.

只有 sysmem 可以呼叫此項目，因為只有 sysmem 是由用戶端進行處理是透過 RegisterSecureMem() 傳送此通訊協定的 FIDL 管道。 Securemem 驅動程式庫是這個通訊協定的伺服器端。

Securemem 驅動程式庫必須將所有涵蓋的偏移值設為受保護的才能順利回覆這封郵件

故障時，securemem 驅動程式必須確保受保護範圍未已建立。

Sysmem 只有在 dynamic_protection_ranges 情況下只能呼叫一次 false。

如果 dynamic_protection_ranges 為 true，Symem 就可以呼叫這個倍數次 max_protected_range_count.

呼叫端不得嘗試新增與已存在的叢集新增的範圍可以彼此重疊，但前提是沒有兩個範圍完全相符

錯誤：

ZX_ERR_BAD_STATE - 當使用者在 !dynamic_protection_ranges。新增會影響整體的堆積堆積數量會超過 max_protect_range_count。
ZX_ERR_INVALID_ARGS - 非預期的堆積或範圍不符對應至 Protected_range_granularity，
ZX_ERR_INTERNAL - 一般內部錯誤 (例如在通訊中) 而 TEE 不會產生 zx_status_t 錯誤)。
其他可能發生的錯誤，例如通訊失敗或 zx_status_t 失敗的伺服器傳播。

要求

名稱	類型
`heap_range`	`SecureHeapAndRange`

回應

名稱	類型
`payload`	`SecureMem_AddSecureHeapPhysicalRange_Result`

DeleteSecureHeapPhysicalRange

從 Symem 到 Securemem 驅動程式庫的要求，要刪除的範圍，若堆積是以透過 sysmem.

Securemem 驅動程式庫必須將所有涵蓋的位移值設為非才會成功回覆此訊息

故障時，securemem 驅動程式必須確保受保護範圍未已刪除。

如果 Dynamic_protection_ranges 為 false，則無法呼叫 Sysmem。

如果 dynamic_protection_ranges 為 true，Symem 就可以重複呼叫此事件。測試期間，系統還會針對不同的網路範圍進行自訂

如果所刪除範圍中的任何部分並不屬於其他範圍受保護的範圍，便是將進行中的 DMA 套用到整個範圍可能會中斷 / 失敗，且可能會幹擾整個系統 (視裝置詳細資料而定，會使用公車鎖定圖文標誌或類似選項)。因此，呼叫端必須確定沒有持續進行的 DMA 刪除範圍的任何部分 (除非呼叫端有其他有效的範圍，涵蓋要刪除的範圍的每個區塊。進行中刪除範圍外封鎖的 DMA 不會受到任何影響刪除。

錯誤：

ZX_ERR_BAD_STATE - 發生 !dynamic_protection_ranges 時呼叫。
ZX_ERR_INVALID_ARGS - 非預期的堆積或範圍不符對應至 Protected_range_granularity，
ZX_ERR_INTERNAL - 一般內部錯誤 (例如在通訊中) 而 TEE 不會產生 zx_status_t 錯誤)。
ZX_ERR_NOT_FOUND - 找不到指定範圍。
其他可能發生的錯誤，例如通訊失敗或 zx_status_t 失敗的伺服器傳播。

要求

名稱	類型
`heap_range`	`SecureHeapAndRange`

回應

名稱	類型
`payload`	`SecureMem_DeleteSecureHeapPhysicalRange_Result`

GetPhysicalSecureHeapProperties

此要求從 sysmem 到 Securemem 驅動程式庫時，會取得受到保護/安全的堆積

這個方法只會以單一連續實體範圍處理堆積。

指出堆積的完整實體範圍，以因應這項要求一些實體空間，以便自動偵測有多少範圍可以使用「REE」。不限系統會先刪除臨時硬體保護範圍，再執行這項要求完成。

新增：7

要求

名稱	類型
`entire_heap`	`SecureHeapAndRange`

回應

名稱	類型
`payload`	`SecureMem_GetPhysicalSecureHeapProperties_Result`

GetPhysicalSecureHeaps

取得實體所在的任何安全堆積的實際地址和長度範圍是透過 TEE 設定

目前這些是固定的實際地址和長度，透過 TEE 滲透的位置

這個方法比 ['fuchsia.hardware.sysmem.Sysmem/RegisterHeap'] 更勝 ['fuchsia.hardware.sysmem.Sysmem/RegisterHeap'] 沒有任何特定 VMO 設定或拆解時這通常代表交易不會十分要求關聯語意

實體範圍必須在 TEE 前受到 TEE 保護/保護 Securemem 驅動程式庫會以成功方式回應這項要求。

Sysmem 應該僅呼叫此一次。傳回零堆積並不是失敗。

錯誤：

ZX_ERR_BAD_STATE - 重複呼叫。
ZX_ERR_INTERNAL - 一般內部錯誤 (例如在通訊中) 而 TEE 不會產生 zx_status_t 錯誤)。
允許執行其他錯誤。任何其他錯誤都應視為與 ZX_ERR_INTERNAL 相同。

要求

<空白>

回應

名稱	類型
`payload`	`SecureMem_GetPhysicalSecureHeaps_Result`

ModifySecureHeapPhysicalRange

從 Symem 到 Securemem 驅動程式庫的要求，要修改的範圍，以及新的基底和長度，範圍是透過 sysmem 設定。

Securemem 驅動程式庫必須將範圍設定為僅涵蓋新的的偏移值，然後回覆此訊息才成功。

失敗時，securitymem 驅動程式庫必須確保該範圍未變更。

如果 Dynamic_protection_ranges 為 false，則無法呼叫 Sysmem。Sysmem 如果 !is_mod_protect_range_available ，則不得呼叫此路徑。

如果 dynamic_protection_ranges 為 true，Symem 就可以重複呼叫此事件。測試期間，系統還會針對不同的網路範圍進行自訂

修改範圍只能在其中一個端或另一端修改，不能同時修改兩者。如果範圍縮短，且未涵蓋的區塊不會涵蓋的其他有效範圍，任何正在進行的指定行銷區域 (DMA) 適用於整個範圍時間縮短可能會失敗導致整個系統受到干擾 (公車鎖定圖文標誌或類似)，因此呼叫端必須確保沒有指定行銷區域持續轉到較短的範圍內，除非修改此範圍後，所覆蓋的封鎖範圍皆為所有仍可變更給其他有效範圍《數位市場法》生效。

如果修改範圍長度小於 0，系統就會刪除該範圍。

錯誤：

ZX_ERR_BAD_STATE - 發生 !dynamic_protection_ranges 時呼叫。
ZX_ERR_INVALID_ARGS - 非預期的堆積，或舊範圍或新範圍不符合 Protect_range_granularity 或舊範圍開頭和結尾不同 (不允許)。
ZX_ERR_INTERNAL - 一般內部錯誤 (例如在通訊中) 而 TEE 不會產生 zx_status_t 錯誤)。
ZX_ERR_NOT_FOUND - 找不到指定範圍。
其他可能發生的錯誤，例如通訊失敗或 zx_status_t 失敗的伺服器傳播。

要求

名稱	類型
`range_modification`	`SecureHeapAndRangeModification`

回應

名稱	類型
`payload`	`SecureMem_ModifySecureHeapPhysicalRange_Result`

ZeroSubRange

透過以下引數新增的現有實體範圍：0 AddSecureHeapPhysicalRange()。子範圍必須完整涵蓋只能有一個實體範圍，不得與任何其他和實體範圍

is_covering_range_explicit - 如果設為 true，則涵蓋範圍必須為一透過 AddSecureHeapPhysicalRange() 明確建立的範圍可能已修改。如果設為 false，則涵蓋範圍不得是其中一個明確建立的範圍 AddSecureHeapPhysicalRange()，但涵蓋範圍必須存在翻唱範圍不是透過 AddSecureHeapPhysicalRange() 建立覆蓋範圍通常是整個實體範圍具體涵蓋 TEE 所設定的堆積，以及則會透過 GetPhysicalSecureHeaps() 傳遞給 sysmem。

這項要求不會中斷持續的 DMA。

要求

名稱	類型
`is_covering_range_explicit`	`bool`
`heap_range`	`SecureHeapAndRange`

回應

名稱	類型
`payload`	`SecureMem_ZeroSubRange_Result`

結構

BufferCollectionConstraints

BufferCollection 參數的限制。您可以。Symem 服務實作受到多位參與者的限制

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	說明	預設
`usage`	`BufferUsage`	這個用法只是提示 sysmem 能選擇更好的模型有多種相容選項時，可使用 PixelFormat 或類似功能。匯總 BufferCollectionConstraints 時，BufferCollectionConstraints 的值為 bitwise-OR。至少須指定一個用量位元，除非整個用量由於 !has_constraints，BufferCollectionConstraints 在邏輯上為空值。	無預設
`min_buffer_count_for_camping`	`uint32`	參與者可同時並行的緩衝區數量專供非短暫使用時間 (開放訓練)。舉例來說，影片解碼器會指定 (至少) 的參考影格 + 目前已解碼 1 個影格。參與者不得坐在超過此處指定的緩衝區數量 (除非否則處理程序可能會停滯匯總 BufferCollectionConstraints 時，請新增這些值。在測試情境中，露營所使用的緩衝區比長時間下來可能會 (最好) 標記為失敗。於測試情境時，系統可能不會為參與者提供更多緩衝區以同樣的方式	無預設
`min_buffer_count_for_dedicated_slack`	`uint32`	讓每位參與者所需的緩衝區數量下限以便處理重疊消息 / 提升效能。匯總 BufferCollectionConstraints 時，請新增這些值。參與者通常會在此處指定 0 或 1，通常為 0 如果 min_buffer_count_for_camping 已足夠與會者相比，參與者有 100% 的時間處於忙碌狀態之後，如果緩衝區超過 1 個，則適合 1 個讓露營變得充足，且 100% 的時間都維持在忙碌狀態 (略落後，在沒有額外緩衝的情況下，百分比較低)。在測試情境中，欄位可能強制設為 0，而所有都希望參與者可以繼續工作如果正向進度需要一個緩衝區，該緩衝區應該也就是 min_buffer_count_for_camping。	無預設
`min_buffer_count_for_shared_slack`	`uint32`	類似 min_buffer_count_for_dedicated_slack，但匯總作業時除外這些值的上限 (而不是 add)。這裡的值不會分享給任何參與者的 min_buffer_count_for_dedicated_slack。參與者可以指定 >如果參與者想確保會有一些配件但不必特別留意選擇要使用 min_buffer_count_for_dedicated_slack 或 min_buffer_count_for_shared_slack (或兩者) 通常是關於額外配量提升幅度在測試情境中，欄位可能強制設為 0，而所有都希望參與者可以繼續工作如果正向進度需要一個緩衝區，該緩衝區應該也就是 min_buffer_count_for_camping。	無預設
`min_buffer_count`	`uint32`	特別挑逗的參與者可能會需要費心緩衝區數量有限，甚至是特定 buffer_count 值。這個欄位應保留為 0，除非參與者確實將這個欄位設為限制整體 BufferCollectionInfo_2.buffer_count。任何如此參與者仍應填寫 min_buffer_count_for_* 欄位。	無預設
`max_buffer_count`	`uint32`	0 會視為 0xFFFFFFFF。	無預設
`has_buffer_memory_constraints`	`bool`	BufferCollectionSettings.buffer_settings 的限制。想指定 image_format_constraints_count > 的參與者1 分會透過以下方式，以隱含方式指定緩衝區空間下限： image_format_constraints ，且只能指定緩衝區空間上限透過 buffer_memory_constraints 來覆寫	無預設
`buffer_memory_constraints`	`BufferMemoryConstraints`		無預設
`image_format_constraints_count`	`uint32`	儲存的圖片格式參數的選用限制它就在 BufferCollection 的緩衝區中。包括像素格式和圖像版面配置這些限制是以像素為單位，因此多項限制或允許。清單中的項目必須有專屬的 pixel_formats。匯總時，只有所有項目指定的像素格式含有非零 image_format_constraints_count (且非空值的) 的參與者 BufferCollectionConstraints) 保留的資源都會保留下來。	無預設
`image_format_constraints`	`[32]`		無預設

BufferCollectionConstraintsAuxBuffers

已移除：23 已淘汰：9 新增：7

欄位類型說明預設

need_clear_aux_buffers_for_secure

bool

如果為 true，只有在所有具備以下特性的參與者時，才能選取安全堆積 BufferMemoryConstraints 指定 allow_clear_aux_buffers_for_secure。如果「需要」為 true，「允許」亦必須成立。

如果設為 False，參與者仍可工作，也許能確保會議安全視支援的堆積而定)，而無需清除 AUX 緩衝區。

無預設

allow_clear_aux_buffers_for_secure

bool

如果為 true，參與者將使用清除的 Aux 緩衝區 (如果發生的話) 參與者的角色。如果參與者是製作人，那麼與會者就能填入清晰的 AUX 擁有清楚 (未加密、未受 DRM 保護) 位元組的緩衝區，以及在受保護的位元組中填入無法模擬範例程式碼的資料，例如：與 0xFF 一樣

如果請按一下「允許」如果參與者指定使用方法，則為 true 也就是唯讀

如果具有寫入功能的參與者未指定，或 false，如果任何參與者指定緩衝區集合，則無法配置需要_clear_aux_buffers_for_secure true。

無預設

BufferCollectionInfo 資源

定義於 fuchsia.sysmem/collections_deprecated.fidl

已淘汰。使用 ['fuchsia.sysmem2.BufferCollectionInfo']。

這個類型已淘汰，但部分相機程式碼仍使用。

欄位	類型	說明	預設
`buffer_count`	`uint32`	集合中的緩衝區數量。	無預設
`format`	`BufferFormat`	說明如何表示緩衝區內容的表示方式。集合中的所有緩衝區都具有相同格式。	無預設
`vmos`	`vmo[64]`	集合中每個緩衝區的 VMO 控點。只有在緩衝區受到 VMO 支援時，VMO 才會出現。如果有，`buffer_count` 之後的所有 VMO 都會是無效的帳號代碼。所有緩衝區 VMO 控制代碼的大小和存取權都相同。 VMO 存取權限取決於是與尋找緩衝區集合時指定的用戶端。例如：若用戶端表示採用唯讀用途，則會接收 VMO，而非寫入權利。	無預設
`vmo_size`	`uint64`	所提供的每個 VMO 大小。只有在緩衝區受 VMO 支援時，系統才會顯示這個屬性。	0

BufferCollectionInfo_2 資源

緩衝區集合及其緩衝區的相關資訊。

已淘汰：23 新增：7

欄位類型說明預設

buffer_count

uint32

緩衝區總數。

無預設

settings

SingleBufferSettings

這些設定適用於初始緩衝區分配中的所有緩衝區。

無預設

buffers

[64]

VMO 會針對集合。

如果有存在，則位於索引 buffer_count 或之後的所有 VMO 均無效 (0) 控點。

所有緩衝區 VMO 控制代碼的大小和存取權都相同。檔案大小位於 settings.buffer_settings.size_bytes。

VMO 存取權限取決於是與尋找緩衝區集合時指定的用戶端。例如：若用戶端表示採用唯讀用途，則會接收 VMO，而非寫入權利。此外，版權可追溯到參數傳送給 BufferCollectionToken.Duplicate() 呼叫。

無預設

BufferFormat

定義於 fuchsia.sysmem/formats_deprecated.fidl

說明如何表示緩衝區內容的表示方式。每種類型的緩衝區是以各自的資料表來描述。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	說明	預設
`tag`	`uint32`	由於這個結構過去只是單一成員聯集，因此我們保留了標記避免任何線路格式變更。這個代碼必須設為 `0` 沒有其他正確值	0
`image`	`ImageFormat`		無預設

BufferMemoryConstraints

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	說明	預設
`min_size_bytes`	`uint32`		0
`max_size_bytes`	`uint32`	0 會視為 0xFFFFFFFF。	4294967295
`physically_contiguous_required`	`bool`		false
`secure_required`	`bool`	如果設為 True，至少要有一位參與者需要安全記憶體。匯總 BufferCollectionConstraints 時，這些值為 boolean-OR。	false
`ram_domain_supported`	`bool`	根據預設，參與者必須確保 CPU 可以在緩衝區沒有快取作業如果它們支援使用 RAM 資料必須在 RAM 內提供 (使用 CPU 快取狀態 RAM 資料不會因為寫入錯誤的 CPU 快取行錯誤資料傳送至 RAM)，且使用 CPU 讀取作業的消費者必須生產者不保證在讀取前撤銷 CPU 快取 (生產端不保證) 沒有過時的「清潔」快取行)	false
`cpu_domain_supported`	`bool`		true
`inaccessible_domain_supported`	`bool`		false
`heap_permitted_count`	`uint32`	選用的堆積限制。不關心哪些堆積的參與者分配記憶體時應保留這個欄位 0	無預設
`heap_permitted`	`[32]`		無預設

BufferMemorySettings

已淘汰：23 新增：7

欄位	類型	說明	預設
`size_bytes`	`uint32`		無預設
`is_physically_contiguous`	`bool`		無預設
`is_secure`	`bool`		無預設
`coherency_domain`	`CoherencyDomain`		無預設
`heap`	`HeapType`	分配緩衝區的特定堆積。如要瞭解堆積 ID 值，請參閱這個檔案。	無預設

BufferUsage

在 fuchsia.sysmem/usages.fidl 中定義的

說明用戶端如何存取緩衝區內容。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	預設
`none`	`uint32`	無預設
`cpu`	`uint32`	無預設
`vulkan`	`uint32`	無預設
`display`	`uint32`	無預設
`video`	`uint32`	無預設

ColorSpace

說明如何呈現圖片中的像素。簡單的色域只需要一個類型。參數色域可能需要額外屬性。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	說明	預設
`type`	`ColorSpaceType`		無預設

FormatModifier

定義於 fuchsia.sysmem/format_modifier.fidl

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位類型說明預設

value

uint64

前 8 位元是在 FormatModifierVendor 中分配到的供應商代碼列舉。較低 56 位元是由供應商定義。

這個欄位和欄位中的值相容性因素。

無預設

ImageFormat

定義於 fuchsia.sysmem/image_formats_deprecated.fidl

說明圖像的呈現方式。

系統已停止支援新程式碼類型，但仍有某些相機程式碼會使用。

欄位	類型	說明	預設
`width`	`uint32`	列寬 (以像素為單位)。	無預設
`height`	`uint32`	列數。	無預設
`layers`	`uint32`	多圖層圖片中的圖層數量。如未指定，預設值為 1。	1
`pixel_format`	`PixelFormat`	像素格式。已淘汰：23 新增：7	無預設
`color_space`	`ColorSpace`	色域。已淘汰：23 新增：7	無預設
`planes`	`[4]`	已淘汰：23 新增：7	無預設

ImageFormatConstraints

說明緩衝區中圖片資料的版面配置限制。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	說明	預設
`pixel_format`	`PixelFormat`	適用下列限制條件的 PixelFormat。A 罩杯參與者可能有多種支援的 PixelFormat 在這類情況下，參與者可以使用 ImageFormatConstraints 清單每個 PixelFormat 都有一個項目其他欄位的值並不常見的 ImageFormatConstraints 變動，例如線性格式，可支援小於圖塊格式的大小上限。	無預設
`color_spaces_count`	`uint32`	空白有誤。重複項目會導致錯誤。任意排序非錯誤。	無預設
`color_space`	`[32]`		無預設
`min_coded_width`	`uint32`	允許的寬度下限 (以像素為單位)。舉例來說，影片解碼器參與者可將這個欄位設為串流可能會指定的最小 coded_width，於相反， required_min_coded_width 設為串流指定的 coded_width。min_coded_width 匯總方法是使用分另請參閱 required_min_coded_width。	無預設
`max_coded_width`	`uint32`	寬度上限 (以像素為單位)。例如，「風景」可能會設定這個欄位 (直接或透過子參與者加入) 可收合至可允許的寬度上限複合詞 0 會視為 0xFFFFFFFF。	無預設
`min_coded_height`	`uint32`	高度下限 (以像素為單位)。例如，影片解碼器參與者將這個欄位設為串流指定的 coded_height。	無預設
`max_coded_height`	`uint32`	高度上限 (以像素為單位)。例如，「風景」可能會設定這個欄位 (直接或透過子參與者) 調整至可允許的高度上限複合詞 0 會視為 0xFFFFFFFF。	無預設
`min_bytes_per_row`	`uint32`	必須為大於或等於 0 的 min_coded_width 值，且必須大於或等於這個值。	無預設
`max_bytes_per_row`	`uint32`	必須為大於或等於 0 的 max_coded_width 所隱含的值，且不得小於此值。 0 會視為 0xFFFFFFFF。	無預設
`max_coded_width_times_coded_height`	`uint32`	最大的圖片區域 (以像素為單位) 為 BufferSettings.size_bytes 也可以直接透過此指令強制執行 ] 欄位。 0 會視為 0xFFFFFFFF。	4294967295
`layers`	`uint32`	多圖層圖片中的圖層數量。 0 會視為 1。	1
`coded_width_divisor`	`uint32`	coded_width % 的 width_divisor 必須是 0。 0 會視為 1。	1
`coded_height_divisor`	`uint32`	coded_height % height_divisor 必須是 0。 0 會視為 1。	1
`bytes_per_row_divisor`	`uint32`	個位元組_per_row % bytes_per_row_divisor 必須是 0。 0 會視為 1。	1
`start_offset_divisor`	`uint32`	vmo_usable_start % start_offset_divisor 必須為 0。 0 會視為 1。	1
`display_width_divisor`	`uint32`	display_width % display_width_divisor 必須是 0， 0 會視為 1。	1
`display_height_divisor`	`uint32`	display_height % display_height_divisor 必須是 0， 0 會視為 1。	1
`required_min_coded_width`	`uint32`	required_ 維度界限。與缺少「required_」屬性的對應欄位相比的 start，這些欄位 (設為非零值) 表示要求產生的匯總 non_required_ 欄位會指定空格完全包含每位參與者必備的空格_ 只要使用來自這些領域的小型資料集訓練即可舉例來說，製作人影片解碼器非常適合或者影片解碼器沒有設定因此必須限制可能的維度空間消費者可以接受，但影片必須確保產生的維度範圍至少目前從串流中解碼的尺寸。同樣地，發起特定動態維度情境的發起人但可以要求參與者事先同意沒有固定的維度範圍 (其他情況較早失敗，也許可以使用較小的必要空間)。製作人或發起人在設定這些欄位時更為常見而不是讓消費者設定這些欄位雖然 non-required_ 欄位透過交叉路口來匯總 required_ 欄位透過聯集來匯總。如果設定了 required_max_coded_width 和 required_max_coded_height，因此分配的緩衝區空間夠大，可以容納 required_max_coded_width * required_max_coded_height。 TODO(dustingreen)：更輕鬆地分配最小大小的緩衝區可視需要處理尺寸 / 替代圖片邊界。 0 會視為 0xFFFFFFFF。	無預設
`required_max_coded_width`	`uint32`		無預設
`required_min_coded_height`	`uint32`	0 會視為 0xFFFFFFFF。	無預設
`required_max_coded_height`	`uint32`		無預設
`required_min_bytes_per_row`	`uint32`	0 會視為 0xFFFFFFFF。	無預設
`required_max_bytes_per_row`	`uint32`		無預設

ImageFormat_2

說明圖像的呈現方式。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	說明	預設
`pixel_format`	`PixelFormat`	像素格式。	無預設
`coded_width`	`uint32`	緩衝區中的列寬 (以像素為單位)。必須 >= display_width。可以是 <以 stride_bytes 隱含的寬度	無預設
`coded_height`	`uint32`	列數。必須大於或等於 display_height。	無預設
`bytes_per_row`	`uint32`	以位元組 0 為單位。飛機 0 以外的飛機 (如有，取決於 pixel_format) 與平面 0 的步距有已知的固定關係。對於 Intel 圖塊紋理，步距適用於紋理的線性化版本。	無預設
`display_width`	`uint32`	要顯示的列寬度 (以像素為單位)。這個值可以是 <= 編碼的寬度。圖片右側 (左側) 有任何裁剪。	無預設
`display_height`	`uint32`	要顯示的列數。這類值可以是 <= coded_height，或是任何會裁剪為底部 (非上方)。	無預設
`layers`	`uint32`	多圖層圖片中的圖層數量。	1
`color_space`	`ColorSpace`	色域。	無預設
`has_pixel_aspect_ratio`	`bool`	pixel_aspect_ratio_width : pixel_aspect_ratio_height 是像素顯示比例 (AKA 範例顯示比例又稱 SAR) (AKA Y) 樣本。像素_aspect_ratio 為 1:1 代表正方形像素。A 罩杯像素_aspect_ratio 為 2:1 代表顯示兩次的像素例如圖像和高度導入轉碼器時，應確保兩個值相對應高於預期值一起分享。如果 has_pixel_aspect_ratio == false，則像素_aspect_ratio 不明。在某些情況下可以使用預設值 1:1，但一樣可以消費者可以按 OOB 法判斷實際的 pixel_aspect_ratio。	false
`pixel_aspect_ratio_width`	`uint32`		1
`pixel_aspect_ratio_height`	`uint32`		1

ImagePlane

定義於 fuchsia.sysmem/image_formats_deprecated.fidl

這種類型已淘汰，而且不會直接取代 (刻意取代)， fuchsia.images2 不需要分別描述每個飛機。

已淘汰：23 新增：7

欄位	類型	說明	預設
`byte_offset`	`uint32`	圖片開頭的平面開始的位元組偏移。	無預設
`bytes_per_row`	`uint32`	每列的位元組。只適用於線性緩衝區格式。	無預設

ImageSpec

定義於 fuchsia.sysmem/image_formats_deprecated.fidl

說明配置某些所需形式之映像檔的限制。

已淘汰：23 新增：7

欄位	類型	說明	預設
`min_width`	`uint32`	寬度下限 (以像素為單位)。	無預設
`min_height`	`uint32`	高度下限 (以像素為單位)。	無預設
`layers`	`uint32`	多圖層圖片中的圖層數量。如未指定，預設值為 1。	1
`pixel_format`	`PixelFormat`	像素格式。	無預設
`color_space`	`ColorSpace`	色域。	無預設

Node_IsAlternateFor_Response

欄位	類型	說明	預設
`is_alternate`	`bool`		無預設

PixelFormat

說明圖片中的像素的表示方式。簡易格式只需要一種類型。參數性像素格式可能需要額外屬性。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

欄位	類型	說明	預設
`type`	`PixelFormatType`		無預設
`has_format_modifier`	`bool`	這個布林值實際上會將 format_modifier 設為選用項目，以滿足「For 淘汰 CBindings」以滿足「FIDL Simple C Bindings」。	無預設
`format_modifier`	`FormatModifier`		無預設

SecureMem_AddSecureHeapPhysicalRange_Response

在 fuchsia.sysmem/secure_mem.fidl 中定義

<空白>

SecureMem_DeleteSecureHeapPhysicalRange_Response

在 fuchsia.sysmem/secure_mem.fidl 中定義

<空白>

SecureMem_GetPhysicalSecureHeapProperties_Response

在 fuchsia.sysmem/secure_mem.fidl 中定義

欄位	類型	說明	預設
`properties`	`SecureHeapProperties`		無預設

SecureMem_GetPhysicalSecureHeaps_Response

在 fuchsia.sysmem/secure_mem.fidl 中定義

欄位	類型	說明	預設
`heaps`	`SecureHeapsAndRanges`		無預設

SecureMem_ModifySecureHeapPhysicalRange_Response

在 fuchsia.sysmem/secure_mem.fidl 中定義

<空白>

SecureMem_ZeroSubRange_Response

在 fuchsia.sysmem/secure_mem.fidl 中定義

<空白>

SingleBufferInfo 資源

目前沒有這個類型的替換項目請透過單一集合使用增量緩衝區分配，

已淘汰：23 新增：7

欄位	類型	說明	預設
`settings`	`SingleBufferSettings`		無預設
`buffer`	`VmoBuffer`		無預設

SingleBufferSettings

在初始緩衝區分配後，即可關閉舊的緩衝區，並來分配新的緩衝區新的緩衝區分配設定時，與集合中的其餘緩衝區不同緩衝區設定會透過 OnSingleBufferAlChanged() 使用 struct:

已淘汰：23 新增：7

欄位類型說明預設

buffer_settings BufferMemorySettings 無預設

has_image_format_constraints

bool

若是保留未壓縮圖片資料的緩衝區，就不會有這個欄位。保留未壓縮圖片資料的緩衝區這個欄位

目前至少要重新配置 PixelFormat 緩衝區。

無預設

image_format_constraints ImageFormatConstraints 無預設

VmoBuffer 資源

已淘汰：23 新增：7

欄位類型說明預設

vmo

handle<vmo>?

同一個 VMO 可由多個 CodecBuffer 使用 ( buffer_lifetime_ordinal)，但每個 Vmo 控點都必須使用不同的帳號代碼。

如果這是 BufferCollectionInfo_2 中的 VmoBuffer，則 vmo 欄位可以是 0 等於或大於 BufferCollectionInfo_2.buffer_count

無預設

vmo_usable_start

uint64

在第一個可用位元組的 VMO 中偏移。必須小於是 VMO 的並且保留足夠的空間 BufferMemorySettings.size_bytes 比 VMO 結束之前。

無預設

ENUMS

CoherencyDomain 嚴格

類型：uint32

只有在沒有以 CPU 為基礎存取緩衝區。Secure_required 緩衝區仍可使用 CoherencyDomain CPU 或即使 Secure_required 緩衝區只能在下列情況下由 CPU 存取，RAM CPU 會以安全模式 (或類似) 執行。反之，裝置本機或是無法透過 CPU 存取的記憶體是 CoherencyDomain Inaccess 即使有可能讓裝置 (實體或虛擬) 複製也就是從無法存取的緩衝區輸出的資料，以及可供 CPU 查看的緩衝區。

已淘汰：23 新增：7

名稱	值	說明
CPU	`0`
RAM	`1`
無法存取	`2`

ColorSpaceType 嚴格

類型：uint32

此清單針對色彩空間標準的每個子類，分別提供一個項目。

因此，如果我們支援 RGB 變化版本 709，我們會在這份清單中新增該變化版本專屬的項目。同樣是 2020 或 2100 的 RGB 變化版本。同樣地，針對 YcCbcCrc 變化版本 2020 年。同樣地，ICtCp 變體為 2100。

指定 ColorSpaceType 可能允許用於以下用途的 PixelFormatType(s) 提供與 ColorSpaceType 的以及官方規格的正式版本並非所有規格有效的組合都受支援。如要瞭解最佳情況度，請參閱 ImageFormatIsSupportedColorSpaceForPixelFormat() 但「true」並不保證所有指定可滿足期望的組合 ColorSpaceType 和 PixelFormatType。

Symem 服務可協助尋找雙向支援的組合，並分配適當的緩衝區。

ColorSpaceType 的規格不會隱含擴充為支援未達到標準的位元/樣本 (R、G、B 或 Y 樣本)。例如：不適用於 2020 和 2100，則不支援 8 位元每 Y 樣本 (由 sysmem 提供)，因為 8 位元/Y-Y 樣本未符合 2020 或 2100 的規格。系統嘗試宣傳並支援 PixelFormat + ColorSpace 這類非標準將導致 sysmem 拒絕組合並失敗分配 (刻意不建議您指定定義不足的組合)。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

名稱	值	說明
無效	`0`	顏色空間類型無效。
SRGB	`1`	sRGB
REC601_NTSC	`2`	601 NTSC (「525 行」) YCbCr 原色，窄版
REC601_NTSC_FULL_RANGE	`3`	601 NTSC (「525 行」) YCbCr 初版本，寬版
REC601_PAL	`4`	601 PAL (「625 行」) YCbCr 初選，窄版
REC601_PAL_FULL_RANGE	`5`	601 PAL (「625 行」) YCbCr 初選，寬版
REC709	`6`	709 YCbCr (非 RGB)
REC2020	`7`	2020 YCbCr (非 RGB，而非 YcCbcCrc)
REC2100	`8`	2100 YCbCr (非 RGB，而非 ICtCp)
PASS_THROUGH	`9`	像素格式不代表顏色，就是應用程式特定的顏色空間，無法由另一個項目描述列舉這些例子
DO_NOT_CARE	`4294967294`	sysmem 用戶端明確指出 sysmem 用戶端確實不考慮選擇 / 使用的色域新增：10

HeapType strict

類型：uint64

已知的堆積類型。裝置專屬類型應設定位元 60。最高訂單位元已保留而且不得設定

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

名稱	值	說明
SYSTEM_RAM	`0`
AMLOGIC_SECURE	`1152921504606912512`	堆積用於阻塞性保護記憶體。
AMLOGIC_SECURE_VDEC	`1152921504606912513`	堆積用於解密與影片解碼之間受阻塞記憶體的堆積。
GOLDFISH_DEVICE_LOCAL	`1152921504606978048`	Goldfish vulkan 使用的堆積，用於裝置本機記憶體。
GOLDFISH_HOST_VISIBLE	`1152921504606978049`	金魚 Vulkan 使用的堆積，用來存放主機可見記憶體。
框架	`1152921504607043585`	用於顯示 framebuffer 的堆積。顯示器會使用這項資訊限制於特定實體地址的單一 framebuffer。 Framebuffer 堆積可讓您建立緩衝區集合並在這些驅動程式中啟用 sysmem 支援

PixelFormatType 嚴格

類型：uint32

格式名稱中的管道順序代表管道的實際版面配置

每個值都須由 RE 決定。例如可以自訂的色域 (與 Vulkan 相比)。

必須與 fuchsia.sysmem2.PixelFormatType 同步。

此類型已不再適用新的程式碼，但仍用於某些相機程式碼。

名稱	值	說明
無效	`0`
R8G8B8A8	`1`	僅限 RGB，每個 R/G/B/A 樣本各 8 位元與 VK_FORMAT_R8G8B8A8_UNORM 相容。
BGRA32	`101`	32bpp BGRA，1 面。僅限 RGB，每個 B/G/R/A 樣本 8 位元。與 VK_FORMAT_B8G8R8A8_UNORM 相容。
I420	`102`	僅限 YUV，每個 Y 樣本 8 位元與 VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM 相容。
M420	`103`	僅限 YUV，每個 Y 樣本 8 位元與任何 vulkan 格式都不相容。
NV12	`104`	僅限 YUV，每個 Y 樣本 8 位元與 VK_FORMAT_G8_B8R8_2PLANE_420_UNORM 相容。
YUY2	`105`	僅限 YUV，每個 Y 樣本 8 位元與 VK_FORMAT_G8B8G8R8_422_UNORM 相容。
MJPEG	`106`
YV12	`107`	僅限 YUV，每個 Y 樣本 8 位元與 VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM 相容。U 飛機可能位於以下兩者之一：圖片的 B 或 R 平面 (如果是 V 平面)；順序可能是通過內部研究 `VkBufferCollectionPropertiesFUCHSIA.samplerYcbcrConversionComponents`。
BGR24	`108`	24 bpp BGR，1 圈。僅限 RGB，每個 B/G/R 樣本 8 位元與 VK_FORMAT_B8G8R8_UNORM 相容。
RGB565	`109`	16bpp RGB、1 平面。5 位元 R、6 位元 G、5 位元 B 與 VK_FORMAT_R5G6B5_UNORM_PACK16 相容。
RGB332	`110`	8bpp RGB、1 平面。3 位元 R、3 位元 G、2 位元 B 與任何 vulkan 格式都不相容。
RGB2220	`111`	8bpp RGB、1 平面。2 位元 R、2 位元 G、2 位元 B 與任何 vulkan 格式都不相容。
L8	`112`	8bpp，純亮 (紅色、綠色和藍色具有相同的值)。與 VK_FORMAT_R8_UNORM 相容。
R8	`113`	8bpp，僅限紅色 (綠色和藍色會被解讀為 0)。與 VK_FORMAT_R8_UNORM 相容。
R8G8	`114`	16bpp RG，1 號飛機。8 位元 R、8 位元 G。與 VK_FORMAT_R8G8_UNORM 相容。
A2R10G10B10	`115`	32bpp RGBA、1 平面。2 位元 A、10 位元 R/G/B。與 VK_FORMAT_A2R10G10B10_UNORM_PACK32 相容。
A2B10G10R10	`116`	32bpp BGRA，1 面。2 位元 A、10 位元 R/G/B。與 VK_FORMAT_A2B10G10R10_UNORM_PACK32 相容。
DO_NOT_CARE	`4294967294`	sysmem 用戶端明確指出 sysmem 用戶端確實不在乎所選擇 / 使用的像素格式。設定這個值時 sysmem 用戶端不得設定 format_modifier_value。新增：10

資料表

BufferCollectionTokenGroupCreateChildRequest 資源

Ordinal	欄位	類型	說明
1	`token_request`	`server_end<BufferCollectionToken>`	必須設定。
2	`rights_attenuation_mask`	`uint32`	如果未設定，則預設值為 ZX_RIGHT_SAME_RIGHTS。

SecureHeapAndRange

在 fuchsia.sysmem/secure_mem.fidl 中定義

已淘汰：23 新增：7

Ordinal	欄位	類型	說明
1	`heap`	`HeapType`
2	`range`	`SecureHeapRange`

SecureHeapAndRangeModification

在 fuchsia.sysmem/secure_mem.fidl 中定義

已淘汰：23 新增：7

Ordinal	欄位	類型
1	`heap`	`HeapType`
2	`old_range`	`SecureHeapRange`
3	`new_range`	`SecureHeapRange`

SecureHeapAndRanges

在 fuchsia.sysmem/secure_mem.fidl 中定義

已淘汰：23 新增：7

Ordinal	欄位	類型	說明
1	`heap`	`HeapType`	這會是安全/受保護的堆積。
2	`ranges`	`vector<SecureHeapRange>[128]`	實體範圍清單。這份清單中的排序依據 entity_address (由低至低)，且不得重疊範圍。系統允許直接相鄰的範圍 (不得重疊)。

SecureHeapProperties

在 fuchsia.sysmem/secure_mem.fidl 中定義

已淘汰：23 新增：7

Ordinal	欄位	類型	說明
1	`heap`	`HeapType`	為了方便起見，這裡重複顯示 HeapType。
2	`dynamic_protection_ranges`	`bool`	如果為 true，系統會針對同一個參數發出多次呼叫 SetPhysicalSecureHeap() 可以使用堆積。如果為 false，則只有一個 SetPhyscialSecureHeap() 呼叫且不允許對 DeleteSecureHeapPhysicalRange() 或允許使用 ModifySecureHeapPhysicalRange()。即使這個情況是 false SecureMem 伺服器 (驅動程式庫) 仍須負責解除防護就會進入暖重新啟動前，如果受保護的範圍不允許清除所用資源。
3	`protected_range_granularity`	`uint32`	保護措施範圍的精細程度。如果起始精細程度為以外的結尾或長度不同之間的精細程度值這必須是 2 的次方。用戶端不得要求可以更精細地指定較小的精細度此值至少須為 zx_system_page_size()，即使 HW 可以也就是較小的 BERT 模型
4	`max_protected_range_count`	`uint64`	SecureMem 伺服器不應計算 SecureMem 的保留範圍伺服器會在內部使用，以從範圍組合 A 到範圍組合 B (如果 SecureMem 伺服器必須對該類型執行任何模擬作業。通常如此不需要透過 SecureMem 伺服器進行模擬。如果有任何範圍由 SecureMem 伺服器所保留，這些保留範圍供 SecureMem 用戶端使用。如果範圍數量侷限於可用記憶體範圍 SecureMem 伺服器對此值回報 0xFFFFFFFFFFFFFFFF。欄位仍必須設定。一如往常，SecureMem 伺服器 SetPhysicalSecureHeapRanges() 的話，一定會成功或失敗 ( 完整更新或復原完成前)。
5	`is_mod_protected_range_available`	`bool`	如果為 true，則會實作 ModifySecureHeapPhysicalRange()。撥號中 is_mod_protect_range_available 時修改 SecureHeapPhysicalRange() 即為 false。請不要試圖偵測修改 SecureHeapPhysicalRange()，以查看失敗的情況；該資料來源可能會 ZX_PANIC()。

SecureHeapRange

在 fuchsia.sysmem/secure_mem.fidl 中定義

已淘汰：23 新增：7

Ordinal	欄位	類型	說明
1	`physical_address`	`uint64`	至少須對齊 heap_range_granularity。
2	`size_bytes`	`uint64`	至少須對齊 heap_range_granularity。

SecureHeapsAndRanges

在 fuchsia.sysmem/secure_mem.fidl 中定義

已淘汰：23 新增：7

Ordinal	欄位	類型	說明
1	`heaps`	`vector<SecureHeapAndRanges>[32]`

聯合國

Node_IsAlternativeFor_Result 嚴格